On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
And, sure, that'd be OK with me, and would probably be better than
adding another exception, so I'm OK with skipping #3. (We
definitely
shouldn't omit #2, though.)
Seems straightforward enough, but... Why are we doing this again?
It
still seems like non-standard behavior. Are we simply attempting
to
avoid the case where folks would get the "nobody" behavior
unexpectedly
because of a mountd bug, or is there more to it?
That's all there is to it. As I said:
2. In the absence of sec=, we should probably *not* choose
AUTH_NULL. (All mountd's before 1.1.3 list AUTH_NULL first
on
the returned list, so users with older servers may wonder
why a
client upgrade is making files they create suddenly be
owned by
nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
I'm just thinking of what the documenting comment might say, and
perhaps
some explanation added to nfs(5).
"As a special case, to work around bugs in some older servers, the
client will never automatically negotiate auth_null; if auth_null is
desired, an explicit "sec=null" on the commandline is required."
Or something like that.
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?
How does the kernel construct a list of client-supported auth flavors?
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.
I think allowing the mount to proceed with AUTH_UNIX is the best
choice here.
--
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
