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

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.

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.

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