Re: Open issues on draft-ietf-krb-wg-general-pac

On Wed, 2012-02-15 at 16:54 -0500, Jeffrey Hutzelman wrote:
> On Wed, 2012-02-15 at 15:18 -0600, Nico Williams wrote:
> > On Wed, Feb 15, 2012 at 11:45 AM, Sam Hartman <[email protected]> wrote:
> > > 4) Why is it domain not realm?
> > >
> > > Some of this has been fixed in the recent draft, but we should have a better understanding of where we
> > 
> > Because it's getting to be time to accept that realms are named after
> > domains?  :)  But, sure, the right thing is to say "realm".
> > 
> > > 6)  Home directories and URIs
> > >
> > > Will require discussion on the list.
> > 
> > We had one today on the concall.
> > 
> > Simo seemed to think that the URIs would be for all the possible
> > locations of a user's home directory on potentially thousands of
> > servers.  But that's not the case, at least I can't think of any case
> > where one would want that, and IIUC neither could Jeff H.
> > 
> > My point is that a POSIX path can be a URI (/net/server/path) or not,
> > but if not and there's no local homedir then we'll need... a federated
> > automount map?  No, that's too much complexity.  What Jeff and I are
> > asking for would be optional: a sequence of zero, one, or more URIs,
> > but probably never more than one per relevant URI scheme.  Even if
> > Simo himself has no use for this Jeff and I believe we do.
> 
> So, as I mentioned on the call, I believe the question of whether we
> have a single item or a list is separable from the question of whether
> the item(s) can be URIs or if only paths are permitted.
> 
> I don't actually think "path plus list of URIs" fits the bill.  This
> field should tell the target service where to find the user's homedir
> (which could be one place or a list of places to search); in the event
> that it's on some server, we have business telling the target service
> where the fileserver/whatever is, but not where to mount/copy/install it
> on the local machine.  This is somewhat confused by the fact that the
> most common cases for "where to find it" are going to be paths visible
> on that machine (either locally or via some distributed namespace), and
> the most common thing to do with those is just use them as the homedir.

Although I agree a local machine can always override whatever path we
pass in as a hint, I think we absolutely need to pass in the actual path
if available.

At least in the Linux world, way too many applications store absolute
file names in their configurations, data, etc... if you do not use the
"canonical" path to mount the home directory you are up for surprises.

> So, what I'd like to see is _one_ list, which can contain zero, one, or
> more than one items.
> 
> The list is first filtered according to local policy and the particular
> situation.  For example, you eliminate items that correspond to
> resources that don't exist or which you don't know how to access or are
> unable to access, and you may also eliminate items due to policy that
> restricts what homedirs are acceptable.  The filtered list is then
> ordered according to some priority rule, which may be some combination
> of local policy and the order provided by the KDC(*).  After that, the
> first (best) item is the one that is used.

Works for me.

> The question of _how_ it gets used is up to the implementation and
> policy.  For example, it might end up being the homedir returned by an
> NSS module, or it might get used in an /etc/passwd entry that gets
> created for that user.  Or it might become where /home/<user> points to,
> or get copied or mounted or symlinked into some local location which
> then gets used as the user's homedir.

Agreed, local policy will always prevail here.

> If there are zero entries left after filtering (possibly because there
> were none to start with), then the behavior is up to local policy.  That
> could mean a (computed or static) default value, or getting the
> information from some other source, or not letting the user do things
> that require having a home directory.

Concur.

> Of course, all of these policy knobs are up to the implementation.  It
> would be reasonable for an implementation to take the first entry, or
> the first entry that is a path, and just use that.  

Agree.

> Separate from this is the question of whether to permit URIs or just
> paths.  This is not a question of representation so much as one of
> whether we can only name directories that can be accessed via the
> filesystem(+) or if we can also name other kinds of remote things.  For
> Windows interop, you might want the user's homedir to be on some CIFS
> server, and named by a UNC path.  But that's not-a-local-path, and no
> different from a URL as Nico proposes (except by being less flexible).

Windows UNC paths can be translated into smb URIs if we want to mandate
URIs.

> Note that I am mostly neutral on the question of whether to permit URIs.
> That's because I don't need them -- I've lived for over 20 years in an
> environment with a global distributed filesystem namespace that looks
> the same on _every_ machine(%), so I _can_ represent homedirs as paths
> that will be the same on every machine that can access them.

I think that if we really want to represent remote resource than a (set
of) URIs is probably the way to go. It would be really sad to see
implementations stuff in arbitrary data that you have to know (somehow)
how to interpret.

A local path can be easily represented by file:///home/user which is
easy to construct from existing directories data by simply slapping
file:// in front of the currently stored path (if any).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg