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

Trond