Nicolas.Williams at sun.com
Tue May 18 12:31:14 EDT 2004
On Tue, May 18, 2004 at 11:18:11AM -0500, Nicolas Williams wrote:
> On Tue, May 18, 2004 at 11:06:49AM -0500, Douglas E. Engert wrote:
> > Nicolas Williams wrote:
> > >
> > > On Tue, May 18, 2004 at 10:50:06AM -0400, Jeffrey Altman wrote:
> > > > Here is my take on the situation:
> > > >
> > > > 1. The current requirement that all paths be specified is too
> > > > complicated for the most common cases in which the recursive path
> > > > traversal in the client would be just fine. Therefore, I would
> > > > like to see recursive path traversal be used when an explicit path
> > > > is not specified.
> > >
> > > Path validation needs a better language that does not require full path
> > > specification.
> > >
> > > I imagine, for example, a language where one can say "not through COM
> > > from *.FOOBAR.COM," "two-hops max from *.FOO.COM," "hierarchical
> > > transits, but not through TLR (top-level realm), shortcuts in hierarchy
> > > traversal allowed from FOO.COM," etc...
> > >
> > This is boggling to the mind!
> It's actually quite simple since most folk will get by with a default
> rule allowing for any transited path and those who don't will generally
> have a few such rules.
Actually, the default rule should be "hierarchical traversals only, with
shortcuts allowed, from any realm."
> > I would expect one goal it to keep it simple, so the client and server
> > can each derive the same path, so as to check the transited field.
> Specifying exceptions is simpler than specifying all valid paths!
Or think of it this way: you may have a set of possible x-realm paths
that's very large and you may want to allow only a sub-set of those to
be accepted by your application, and typically you don't trust a
particular realm or want specific shortcuts taken, so how do you express
such policies? Today you have to express the actual sub-set of x-realm
paths you find acceptable; that is, you have to translate your desired
restrictions into a sub-set of paths, by hand.
Methinks that just expressing the restrictions and letting software
interpret them will be less error prone than what we have now and, in
any case, will be gentler on the sysadmin.
More information about the krbdev