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