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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2009-09-01 at 14:25 -0400, Trond Myklebust wrote:
> 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.

We should also try it if the server is broken, and returns an empty
list, but only after first attempting to cycle through all the other
flavours that are supported by the client.

Trond

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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux