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

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Sep 01, 2009 at 11:52:39AM -0400, Chuck Lever wrote:
>
> On Sep 1, 2009, at 11:18 AM, J. Bruce Fields wrote:
>
>> On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote:
>>> On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
>>>> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>>>>> Currently the kernel's MNT client always uses AUTH_UNIX if no  
>>>>> "sec="
>>>>> mount option was specified.  In the interest of conforming more
>>>>> closely to RFC 2623, teach the MNT client to use the first flavor 
>>>>> on
>>>>> the server's returned authflavor list instead of AUTH_UNIX, if  
>>>>> "sec="
>>>>> was not specified.
>>>>>
>>>>> When the user does not specify "sec=" :
>>>>>
>>>>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX  
>>>>> (unchanged).
>>>>>
>>>>> o  For NFSv3: if the server does not return an auth flavor list,  
>>>>> use
>>>>>   AUTH_UNIX by default; if the server does return a list, use the
>>>>>   first entry on the list by default.
>>>>
>>>> Sounds good, but also:
>>>>
>>>> 	1. Even when sec= is provided, we should probably still check
>>>> 	the passed-in security against the server-returned list.
>>>> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
>>>> 	when no subsequent file operation would, thanks to the
>>>> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
>>>> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>>>>
>>>> 	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
>>>>
>>>> 	3. As a special exception, we should probably allow an explicit
>>>> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
>>>> 	from post-1.1.3 mountd returns will make it otherwise impossible
>>>> 	to mount with AUTH_NULL.
>>>> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>>>>
>>>> Oops, my bad: I see now from the code that you did actually do #1,  
>>>> you
>>>> just didn't mention it above.  OK!
>>>>
>>>> I don't see #2 or #3, though maybe they're already handled
>>>> somewhere....
>>>
>>> No, not in the kernel's MNT client.  #3 seems like a server bug to  
>>> me,
>>> though.
>>
>> Alas, it's apparently a workaround for a client bug: see the url
>> referenced after #3.  (But I don't know what client versions that bug
>> was in.  If someone investigated and found they weren't widely
>> distributed, I'd take a patch to remove the workaround.)
>
> How are clients supposed to tell if the server actually supports  
> AUTH_NULL but didn't list it, versus the admin specifically forbidding  
> the use of AUTH_NULL?

They can't.  So the compromise I proposed was to avoid negotiating
AUTH_NULL automatically, but to allow the user's explicit sec=null to
override the server's returned list.  That said, I think I'm convinced:

> Mountd should list AUTH_NULL if the server admin specified it (although 
> it doesn't need to list AUTH_NULL by default).  The server is allowed to 
> reorder the flavor list, not the client, according to RFC 2623.  The 
> server's admin may even _prefer_ "rw,sec=null" access, in which case 
> listing AUTH_NULL first is actually desired.

And in fact that's the way a recent linux server works.

So if you do #2 above but not #3, then you can tell people: if you
really need auth_null, you need to a) request it explicitly on the mount
commandline, b) upgrade to a recent mountd (at least 1.1.4), and c) list
it explicitly on the server export.

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

--b.