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

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.


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.

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.

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.

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.  



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).

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.


-- Jeff






(*) To be clear, the provided list is ordered, according to how the KDC
has been configured and/or where it got the data.  However, the target
service may have configuration which partially or completely overrides
the order, for example by preferring a local directory over a remote one
even if it occurs later in the list.

(+) That is, can I just chdir there?  If something has to be done to
mount the thing, then this test fails.  Note that automounters let you
have remote paths that are accessible this way, as does use of things
that are pre-mounted.  But those require that the KDC knows something
about the automount map or the things that are pre-mounted.  That's
probably doable in some deployments, but utterly impossible in others.

(%) Actually, when I got here, we had two of those.

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