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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
