Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Peter Staubach <staubach@redhat.com>]

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