Re: NFSv4 behaviour on unknown users

[Neil Brown <neilb@suse.de>]

On Tue, 30 Nov 2010 22:10:02 -0500 Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:

> On Wed, 2010-12-01 at 13:57 +1100, Neil Brown wrote:
> > I have a strong memory from about 7 years ago of Brian Pawlowski saying - or
> > possibly being quoted as saying - that the user information in NFS requests
> > (the stuff that idmapper handles) is totally independent of the RPC
> > authentication mechanism being used (the AUTH_SYS / RPCSEC_GSS stuff).
> > 
> > I always thought that was nonsense, but I wasn't in a position to discuss it
> > at the time for reasons that I really don't recall.
> > 
> > If users are being authorised using numbers (AUTH_SYS) then it only (to me)
> > makes sense to communication all identies as numbers.
> > And if users are being authenticated as name@domain strings, then it only
> > make sense to communicate all identities as name@domain.
> > 
> > But this path is not the path for NFSv4 followed.
> > 
> > I've very glad to see Linux NFS allowing numeric IDs "on the wire" and hope
> > to see this very sensible approach widely adopted (where AUTH_SYS is used).
> > I think it would be great if nfsd did the same thing completely in-kernel
> > without reference to idmapd.  Accepting either numeric or domain-based is
> > trivial.  Choosing which to send on a per-client basis might be a challenge,
> > but probably not a big one.
> > 
> > 
> > I wonder if Brian remembers saying anything like that...
> 
> I think you need to take beepy's words in context here: as I believe I
> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
> everyone would be using principals for authenticating, either through
> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
> everyone of this, that AUTH_SYS isn't even mentioned as a valid
> authentication mechanism, and so nobody had to worry about the
> consequences of using it.
> 
> The fact we still use AUTH_SYS today is, BTW, very much a result of the
> failure of SPKM/Lipkey to deliver on its promise of strong
> authentication with no extra infrastructure requirements. If it had, we
> wouldn't be needing this hack.

Thanks Trond.  You are undoubtedly right, and that does make the comment a
little less strange.
Though I still think that LIPKEY and krb5 are different identification
mechanisms and so assuming that the identities are in the same namespace is
wrong.  Obviously it is possibly to force them to be in the same namespace,
but building that into the protocol as an assumption just seems wrong.

Thanks,
NeilBrown