RE: NFSv4 behaviour on unknown users

["Spencer Shepler" <spencer.shepler@gmail.com>]

> -----Original Message-----
> From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]

<trim>

> > > servers.
> > >
> > > The other problem is that when you use the naked uid or gid you are
> > > losing information about which domain the user belongs to.
> > >
> > > While that may be fine when you are authenticating using the
> > > AUTH_SYS security flavour, it is just plain wrong when you are
> > > authenticating using RPCSEC_GSS principals (which is what the NFSv4
> > > spec assumes that you will use).
> >
> > Then the administrator will not use that option.
> >
> > The use case that was presented did not use Kerberos (at least in my
> quick reading).
> >
> > I agree that users that use Kerberos will be unhappy and that they
> > should use something that maps more in align with their Kerberos
> > realms but that is not the pain point under discussion.  A variation
> > of the id mapping work under discussion by Andy would/could address
> > Kerberos and other deployment scenarios.  But for the original "works
> > for NFSv3 and doesn't for NFSv4" crowd something simple will suffice
> > and they will be happy and stop bitching about this and move onto the
> > next thing that pisses them off. :-)
> 
> It would not be backwards compatible: the linux server will currently
> reject any uid/gid usage by the client.
> 
> That said, I can imagine that for 'sec=sys', we might be able to change
> the client to use the uid/gid format by default, and then change back to
> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
> server.
> It the server changes to match this, then that might suffice solve the
> current problem that we have with doing nfsroot on NFSv4...

IMO: I wouldn't worry about the mixed scenarios to start with.
Provide the option on the client and server to use the straight-up
uid/gid to string mappings and this will satisfy these simple
deployments that are or will have trouble.  In the mixed environments,
there is more work but at least there is something available for
admins to get started with.

Spencer


> 
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com