Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2009-09-01 at 15:31 -0400, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 14:58 -0400, Chuck Lever wrote:
> > On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
> > > On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
> > >> OK, one more corner case.
> > >>
> > >> What if the mount doesn't specify "sec=" and the only flavor in the
> > >> server's auth list is AUTH_NULL?  Seems like we should allow that  
> > >> one.
> > >
> > > Amend the above statement to "the only flavour in the server's auth  
> > > list
> > > that is supported by the client", and I'll agree.
> > 
> > > If a server advertises auth_dh, auth_krb4 and auth_null, then we  
> > > should
> > > definitely try auth_null rather than failing.
> > 
> > What if the list has AUTH_GSS_KRB5 and AUTH_NULL?  Should the kernel  
> > try AUTH_GSS flavors if it can't tell whether gssd is running or there  
> > is a valid local keytab?
> 
> Firstly, we can tell if gssd is running. There is a timeout period of 30
> seconds, but after that timeout, if there are no listeners on the end of
> the gssd pipe, the rpc_pipefs code will return ETIMEDOUT.
> 
> > How does the kernel construct a list of client-supported auth flavors?
> 
> Although we do have the auth_flavors[] list, we don't currently have a
> list that enumerates all the supported pseudoflavours. Instead, we have
> auth_flavors[], and then a separate list of all the rpcsec_gss auth
> mechanisms that are currently loaded into kernel memory.
> I suggest we need to unify the information in those two lists, perhaps
> by having everyone register into a separate list of all pseudoflavours
> that are acceptable as parameters for rpcauth_create().
> 
> > > We should also try it if the server is broken, and returns an empty
> > > list, but only after first attempting to cycle through all the other
> > > flavours that are supported by the client.
> > 
> > 
> > If the server returns an empty list, we can't negotiate.  We are  
> > fairly certain only old Linux servers return an empty list, in which  
> > case the client can assume all we've got is AUTH_NULL and AUTH_UNIX.   
> 
> ...or RPCSEC_GSS/krb5
> 
> > I think allowing the mount to proceed with AUTH_UNIX is the best  
> > choice here.
> 
> As I said, this functionality is in also required in order to make NFSv4
> security negotiation work.

...and for NFSv2 as well...

Trond