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

--b.