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

On 10/11/2011 9:32 PM, Harry Coin wrote:
> On 10/11/2011 9:17 PM, Nico Williams wrote:
>> On Tue, Oct 11, 2011 at 7:56 PM, Harry Coin<[email protected]>  
>> wrote:
>>> So, kindly look at
>>> https://github.com/heimdal/heimdal/blob/master/lib/krb5/aname_to_localname.c. 
>>>
>> I consider that a bug.  MIT doesn't implement this.  MIT does give you
>> the rope with which to implement these sorts of rules.
>>
>>> There is a conflict both with 'kerberos is principal name agnostic' and
>>> gssapi's requirement of host/fqdn format principal names, and 
>>> through that
>>> nfs3 and nfs4 servers forcing local roots with gssapi authenticated 
>>> names to
>>> be 'nobody' no matter -maproot=root on the server when nfs clients.
>> This has nothing to do with the GSS-API.  Or at least I see no
>> evidence that it does have anything to do with the GSS-API.  It's
>> possible that whoever added this (Assar? or maybe this goes back
>> longer and the history is lost) thought this would be a good idea
>> given what the Solaris NFS client does, but the more likely
>> explanation is that this is just a local convention at a Swedish
>> university, and it got baked into Heimdal at a time when there were
>> few users of it.
>>
>> In any case, thanks for bringing this up.  I think it will be best to
>> implement an MIT-like rule system, though perhaps one that is easier
>> to use.
>>
>>> Diskless clients that are forcing =sec:krbX need their root and other
>>> principals to not be 'nobody' to the server file system.  Hence the 
>>> nice
>>> -maproot:=root feature of nfs.   Except names in the format required by
>>> gssapi of x/box@realm are forced to 'nobody' by nfs servers when nfs 
>>> clients
>>> before the -maproot bit has a chance to work on it.
>> NFS is a really poor protocol for diskless /.  The reasons for this
>> are many, and I strongly recommend iSCSI instead for diskless root!
>>
>> NFS is lousy for diskless root because:
>>
>>   - Until RPCSEC_GSSv3 is widely deployed there's no simple way for
>> clients to handle complex process credentials.  For example, a process
>> with a different set of effective privileges (or capabilities, in
>> Linux-speak) than it's euid user normally has, can't have file access
>> faithfully implemented by the client.
>>
>>     The client could use the root credential on the wire, apply
>> additional access controls locally, then chown/chgrp as necessary,
>> sure, but this will leave a window of time during which files are
>> owned by root when they should be owned by a different user.  And if
>> the client is not even smart enough to do this, then access might be
>> denied when it should be allowed.
>>
>>   - Diskless-ness really requires a notion of "share ownership" that
>> doesn't currently exist.  This is not just in connection with the
>> client's "root" principal being privileged enough to have
>> root-equivalent access to its shares.  It's also in connection to, for
>> example, denying other clients access, either in whole or in part,
>> such that the owner client has full control as to locking, and
>> possibly more.
>>
>>     As part of this we need for server implementations to allow the
>> admin to specify what the owning principal is, not to have the vendor
>> dictate conventions like root/fqdn.  And we need RPCSEC_GSSv3, and
>> more.
>>
>>   - Diskless clients can really cache a lot.  Protocol extensions that
>> make it easier for clients to cache and servers to just validate
>> caches most of the time would result in much better performance.
>>
>> You can see how iSCSI doesn't have any of these problems because it's
>> just a block device, and everything that the client needs the client
>> can implement, with the exception of the need to allow only one client
>> to to have a LUN open for writing at a time, which is enforced by the
>> server.  NFS is far from appropriate for diskless-ness at this point
>> -- the world changed, and NFS did not keep up with diskless client
>> needs.
>>
>> And if you think NFS can do better at dedup, well, probably not really
>> much better than iSCSI.  It's probably easier to manage upgrades of
>> images using NFS if you need to extract data from existing images at
>> upgrade time, but this is best avoided.  In short: diskless NFS is not
>> the beast you're looking for.  :)
>>
>> Nico
>> -- 
>>
>
> Thanks for these thoughts.   Leaving the diskless architecture to the 
> side and getting pragmatic here-and-now:
>
> How does a user logged in as root with authenticated credential 
> 'root/[email protected]'  create a file owned by 0:0 nfs 
> shared on box2 with -maproot=root and -sec=krb5?   RIght now, only 
> files owned by 'nobody:root' (love the ':root' bit on linux...) can be 
> created (nfs share is 0:0  mode 0775).   In fact you can substitute 
> anything you like for 'root' in the foregoing,  like 'host' and 
> 'nslcd' and 'nfs'.  Even users whose group is not root, and the nfs 
> share will be owned by nobody:root.    It might be an artifact of 
> Debian being MIT and freebsd 8-stable being heimdal but I do not think 
> so.
>
P.S. of interest, same behaviour NFSv4 or v3.  Normal ownership on new 
files created on the server by clients with any principal other than 
those formatted user/<fqfn>@REALM.