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

On 10/11/2011 10:46 PM, Nico Williams wrote:
> On Tue, Oct 11, 2011 at 9:32 PM, Harry Coin<[email protected]>  wrote:
>> 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.
> I don't really know what options the Linux NFS server for
> root-equivalent access.  So far all I can find are the root_squash and
> no_root_squash options.  If you find any other options -- anything
> like the Solaris root=<list>  option, let us know.

In this example Linux is the client, Freebsd/ZFS the server.   Again to 
be clear all is well until the principal name has more than one part and 
the second is not 'root'.    A user with nonzero uid and non zero gid, 
such as drop root nslcd on linux, when creating a file on the freebsd 
nfs v4 or v3 share, only when kerberos security is enabled, gets mapped 
to 'nobody:root'.       Not 'nobody:nogroup', 'nobody:root'.

So it's not specific to root, its about the form of the principal name.  
Ldapwhoami works, local files all correct, nslcd all work.  It's about 
kerberos somehow.   I thought for sure reverting to nfs3 where the 
uid:gid is on the wire and not the names the behaviour would change.  
Now, the most likley common element is gssd.. and the really unexpected 
code provided  by heimdal which actually does get referred to by nfs.

>
> I find things like:
>
> http://sourceforge.net/project/shownotes.php?release_id=507588
>
> and
>
> http://eeek.borgchat.net/lists/linux-nfs/msg17422.html
>
> where I find this:
>
> | Actually, in the case of UID=0, the client's machine credentials are
> | used.  You can map that Kerberos principal to root on the server.  So
> | this _is_ possible.
>
> So, it seems that the Linux NFS server with RPCSEC_GSS may allow
> root-equivalent access via aname2lname mapping, but just not on a
> per-share basis (Solaris can).
>
> I'll repeat one more time though that there is *no* GSS-API name-type
> of the form<user>@<fqdn>  or<user>/<fqdn>.  The Solaris requirement
> that root-equiv clients must have root/<fqdn>@<REALM>  is something
> that goes back to 1999 and was really a mistake.  There is no
> connection between that name form and GSS, really.

What do you make of rfc1964 sec 2.1.2  "Host-Based Service Name 
Form"where the form of names regarding 'services associated with host 
computers' is set forth?

> I suspect that someone must have thought that having root/fqdn@REALM
> for root-equivalent access + the root= option on shares meant that
> realm admins could know for sure what clients could possibly get
> root-equivalent access.  But the truth is that the server could always
> have done whatever it wanted, and any third party vendor's services
> could have done whatever they wanted.  The moral is, I think, that
> there's not much about an _initiator_ name that could convey
> authorization, and that any conventions to do so need to either be
> local or very carefully standardized (root/fqdn was never
> standardized).  On the acceptor side the acceptor name can convey very
> limited authorization information, with domain-based naming being the
> most interesting name-type in this respect.
>
> Nico
> --
>

Probably took that hint from the RFC. I can't believe how hard it's been 
getting a kerberized nfs server going talking cross nfs platform.  Every 
step a battle and still not there.  First drop root nslcd 'taint ignores 
environment' so hacking the keytab files, then kstart keytab ownership, 
now strangeness getting file ownership correct on servers when there's a 
/ in the client's principal name.