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

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