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

On 10/24/2011 8:56 PM, Nico Williams wrote:
> On Mon, Oct 24, 2011 at 6:19 PM, Harry Coin<[email protected]>  wrote:
>> On 10/24/2011 5:17 PM, Nico Williams wrote:
>>> Now, can you clarify what it is you want?
>> Sure.  I want everything that worked great here to continue as before (ldap,
>> pam_krb5, nslcd, local software) -- except with -sec=krb5x kerberos benefits
>> as advertised.  Specifically
>>
>> A)  without taboo against uid:uname:principal name combinations if I
>> specifically indicate I permit them.
>>
>> and, as pre-kerberos,
>>
>> B) if a server should offer  N directories for remote access, but
>> restricting each of them specifically to F(N) boxes, where F(N)<  all the
>> boxen in the realm, there exists at least one directory available to
>> processes on  box Y but not Z, and likely too some on Z not available to Y.
>>   then:
>>
>> Files written on the share by account-name:uid QQ on Y  will not be
>> available to QQ if on Z.  Such files will appear with the QQ's correct
>> uname:uid.  Should QQ write on Z, such files may not be visible if on Y, but
>> will appear correctly named on Z.   If a process running as QQ exists on the
>> server it will have access to both the files written from Y and from Z by
>> user QQ.
> 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

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

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

The above is the state of things pre-kerberos.  The name 
whatnot/box?.domain.com were chosen because gssapi wants them that way.  
Note user whatnot on box2 has no access to whatnot's files that were 
written on box3, though both are served by box1.

What I want from kerberos is only this:  the ability to add  
"sec=krb5i"  to the exports and mounts... and have nothing else above 
change except I get the wire security advertised.   Before the changes I 
sent to the list, and changing a getpwnam_r array from 128 to 1024, this 
now this did not work. That's why I called it a 'kerberos regression'.  
With the changes, it does.

Why should heimdal stop me from naming principals as I like, so long as 
I give it instructions in /etc/k5login.d about mapping them to and from 
user names?

Harry


>   That would require changes to the application -- changes to the
> Kerberos library alone could not provide that feature.  (Note that
> Solaris, for example, allows only per-share mapping options for
> *root*, not any other local accounts.  What you're asking for, if I
> understood correctly, is a fairly large, though perhaps desirable
> change to NFS servers.)
>
> Can you confirm?
>
> But clearly that can't be it because when I read your patches I see
> something completely different.
>
>> C)   Unames map onto uids in a 1 to 1 way.   Unames map onto
>> 'multi-application-use' kerberos principals in a 1 to 1 way.
> What's a uname?  What's a "multi-application-use Kerberos principal"?
>
>> Just as they all did before kerberos meets network wire integrity/privacy
>> assurance.
> Uh, NFS never had per-share mappings of anything other than UID 0
> before it got kerberized.
>
>> Except, now with the advertised kerberos ability to authenticate the user,
>> or to provide integrity checks of the traffic, or to encrypt the trafffic
>> entirely if asked.
>>
>> Being that it's all free instead of asking for a refund I wrote some patches
>> that get it done.
> 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.


>   - 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 
aname_to_lname db only is not a good idea as it is only one way, not 
helping 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.



Harry