On Sep 1, 2009, at 3:31 PM, 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.
Oh, good! Another 30 second timeout during mount! :-)
But there's still no way to assess the validity or contents of the
client's keytab.
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().
OK, but that seems like more than we should try to do before 2.6.32.
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
The server supports AUTH_GSS but doesn't return a flavor list? I
would like some confirmation that this behavior actually exists in the
field.
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.
This is all added to the kernel's MNT client. None of this logic will
ever be used by NFSv4, unless we refactor it someday. At which time,
we can worry about it then.
...and for NFSv2 as well...
Now you've lost me. The v1 MNTPROC doesn't return a flavor list, so
NFSv2 doesn't support security flavor negotiation at mount time.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
