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

On 10/24/2011 10:00 PM, Nico Williams wrote:
> 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.

But that's only half an answer, kuserok has to accept what aname2lname 
produces.


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

You do keep mentioning this.  sasl client and sasl server just do insist 
otherwise.   Then there's the whole 'reverse ip' thing where apps want 
to confirm addresses and build principal names from service names and 
the reverse dns.   I don't much want the service account user name to be 
different than the service name than what appears before the / in the 
principal name.   Sometimes I think the folk here forget somehow that 
services generally own files, and it's a bad idea for them to all be 
root.   Then we get into the whole 'taint' fiasco.    I just didn't want 
to patch the library in the way Rune suggested as I didn't want to alter 
any current behavior.   My changes don't alter any current behavior, 
(other than failing on the /, and making kerberos an option to 
authenticate local users with no default home directories).  Whether 
they're the right thing forever, well I'll let people for whom heimdal 
is front and center everyday worry about that.

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

Exactly.  Thus breaking the application or forcing the administrative 
burden of creating groups and making all the various members of it, then 
making the files group readable, but I wanted less administrative burden 
with progress, not more.

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

Other than I've already accomplished it without breaking anything that 
presently works, you mean?

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

It's deterministic if the editor of the /etc/k5login.d directory doesn't 
do anything that when they look at it would appear senseless anyhow.  
I'm sure someone could write a little test to validate that no principal 
matches more than one username in /etc/k5login.d  (note it does not 
check the user's home directories.   This adds functionality actually 
since it's possible with this for admins to block the ability of a user 
to affect the behavior of root enabled daemons reading ~/.k5login files.
> 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.

There's no point in bringing a tractor to a move a pea.

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

Hence the line in the code provided  that checks it--- and at least for 
the added behavior I put into aname_to_lname checks that too.   Note the 
present aname to lname quite happly returns the first part of a 
principal name as a user name without checking whether it exists at all!



Harry

> Nico
> --
>