J. Bruce Fields wrote: > On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote: >> 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. >>> >> Some servers will accept any flavor of incoming RPC security >> and just use AUTH_NULL in this situation. It really shouldn't >> matter what the client sends, as long as the server is just >> going to map all requests to nobody/nobody anyway... > > OK, but let's not pile on more workarounds than we have to. I don't see > any reason that we really need to do anything special for servers that > are broken in *that* particular way.... > I don't think that that is considered to be broken, by the way. I am not sure whether it still works this way, but I know that Solaris used to work this way, at the very least. Since I clearly haven't looked, but why would the Linux NFS server care which flavor that it got sent, if the export is configured to map all requests to nobody/nobody? ps -- 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
