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

On Mon, Oct 24, 2011 at 9:31 PM, Harry Coin <[email protected]> wrote:
> On 10/24/2011 8:56 PM, Nico Williams wrote:
>> I'm having a hard time parsing what you write.  But if I understand
>> correctly you want *per-share* mappings of principals to authorization
>> IDs.
>
> Sorry for the difficulty. How about this config file approach to explaining
> things.
> First we start with a working setup---  where I was before I thought to
> protect the wire with kerberos/hiemdal.
>
> box1:/etc/exports
> /work/fs1    box2
> /work/fs2    box3

So box1 is the server and box2 and box3 are the clients.

> On box2:
> box2# mount box1:/work/fs1 /work/fs1
> principal  whatnot/box2.domain.com@REALM --user whatnot uid:800 gid:800
> executes
> box2$ touch /work/fs1/foo; ls -l /work/fs1/foo
> ... whatnot : whatnot ... 0 foo

OK, so you mean that a process on box2 with UID 800 and credentials
for whatnot/box2.domain.com@REALM creates a file and... it looks like
that file is owned by... whatnot?  Sure, that's possible today.

> box2$ldapwhoami -Z
> SASL/GSSAPI authenitcation started..
> ...
> dn:uid=whatnot/box2.domain.com
> box2$ whoami
> whatnot
>
> On box3:
> box3# mount box1:/work/fs2 /work/fs2
> principal  whatnot/box3.domain.com@REALM user whatnot uid:800 gid:800
> executes
> box3$ touch /work/fs2/foo; ls -l /work/fs2/foo
> ... whatnot : whatnot ... 0 foo
> box3$ldapwhoami -Z
> SASL/GSSAPI authenitcation started..
> ...
> dn:uid=whatnot/box3.domain.com
> box3$ whoami
> whatnot

If I understand what you want, gthen yes, all you need is a
aname2lname DB.  Again, the Linux and Solaris NFS servers have one of
their own plus they can use the krb5 library's aname2lname.  I don't
know about FreeBSD's NFS server.

I agree that aname2lname should have a DB option.

> On box1, there is no way to log in as 'whatnot'.  su 'whatnot' gives:
> box1$ ls -l /work/fs1
> ... whatnot : whatnot ... 0 foo
> box1$ ls -l /work/fs2
> ... whatnot : whatnot ... 0 foo

OK, fine.  No changes are needed to the NFS server for *that*, well,
except that... [see below].

> The above is the state of things pre-kerberos.  The name
> whatnot/box?.domain.com were chosen because gssapi wants them that way.

No, the GSS-API does not "want" them that way.  That's your imagination :)

Yes, you *can* use principal names of that form.  The GSS-API doesn't
force you to.  And no GSS app that I know of forces you to use
*client* principal names of that form (with the exception I've
described before for root-equivalent access in the Solaris NFS
server).

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

>> Do the patches address your problem?  Can you characterize what the
>> patches do?  Or confirm my characterization?  Here's what I think your
>> patches do:
>>
>>  - add a simple database for aname2lname mapping consisting of k5login
>> files named /etc/k5login.d/<username>; aname2lname() checks *all* of
>> these in dirent order!!
>
> For each principal having one or more / in the name, not of the form
> */root@REALM, it checks the cache.  Then instead of failing altogether as
> the present code does, it checks the files in /etc/k5login.d only.  There
> are few, there and pattern matching is enabled.  So it's not worse than
> re-loading krb5.conf every time a context is initialized.  Having found one,
> it puts it in a cache for 5 minutes.

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.

By using a DB (Berkeley DB2, 3, 4, SQLite3, cdb, a flat text sorted
file, ...) you avoid the need for a cache, and you avoid the
non-deterministic behavior.

>>  - add an in-memory cache for aname2lname() and kuserok() results.
>>
>> Is that a fair summary?
>>
>> If so, the change to aname2lname is completely unacceptable.
>
> Well, now you see the summary isn't accurate.  Anyway, adding the

I think it was accurate.

> aname_to_lname db only is not a good idea as it is only one way, not helping

Yes, we need an aname2lname DB.

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

Nico
--