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