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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

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.

Trond