Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Mon, 2011-10-24 at 22:00 -0500, Nico Williams wrote:
> On Mon, Oct 24, 2011 at 9:31 PM, Harry Coin <[email protected]> wrote:
> >  Note user whatnot on box2 has no access to whatnot's files that were
> > written on box3, though both are served by box1.
> 
> *That* is not possible today.  Well, it is, but only if you map
> whatnot/box2 and whatnot/box3 to different usernames on the server, so
> that ls -l on box1 will show those two files as owned by different
> users.  It *could* be made possible without having to map those two
> principals to different users, but I'm not sure that's worth it, and
> anyways, it would mean that the aname2lname DBs are per-share, and
> then you've left the realm of problems that you can solve entirely in
> libkrb5.

No, there's another way.  If whatnot@box2's files are all in a directory
tree that is _not exported to box3_ and vice versa, then indeed neither
user can access the other's files, even though they have the same UID on
the server, and the user whatnot on the server can access both sets of
files, provided all three have the same (server-side) UID.

Of course, this has _nothing to do with Kerberos_.  It's just applying
IP-address-based access control, with all of the weaknesses that's
always had.  If the owner of box2 uses whatnot/box2's tickets but spoofs
box3's IP address, he will be able to access whatnot/box3's files.


> Not acceptable.  Use a real DB, not a directory of k5login files
> searched in dirent order.  I'm irrevocably opposed to
> non-deterministic aname2lname behavior.

Non-deterministic behavior is a bad idea here, yes.  But something
deterministic would be fine.  However, I'd ditch the idea that the
file's name is significant for anything other than search order, and
instead let the file(s) contain (user,principal) pairs.  You still have
to search every entry, but you gain a lot of flexibility.

> > the kuserok problem at all.   This approach solves both problems and makes
> > it possible for users that have no 'default directory'  ( grep nonexistent
> > /etc/passwd) to be associated with kerberos principals, and only then is it
> > possible for them to read and write over a network.
> 
> I'm opposed to having kuserok ever return TRUE for users for which
> getpwnam() does not return a struct passwd.

Agreed.  However, I'm not entirely opposed to the idea that a
user's .k5login file might live in a central place controlled by the
system administrator instead of in the user's home directory.

-- Jeff