Re: mount.nfs: access denied by server

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

On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
> On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>> I want to understand the server bug a little more.  I glanced over  
>>> RFC
>>> 2623 and didn't see anything specific.
>>>
>>> Is it the case that only Linux NFSD does this, or do other servers do
>>> it?  In other words, is this a typical server response, and if so, is
>>> there a specific semantic attached to it?
>>>
>>> If no list is provided, should the client assume that only AUTH_NONE 
>>> and
>>> AUTH_SYS are supported, or instead, perhaps that the client can try  
>>> to
>>> use any flavor?  In other words, if no list is provided, let the  
>>> mount
>>> proceed no matter what was specified by sec= ?
>>
>> I think the safest behavior on the client would be something like:
>>
>> 	- If an explicit sec= is provided on the client, try that
>> 	  flavor.  Otherwise:
>> 		- If the server returned a nonempty list, pick something
>> 		  off that list.  Otherwise:
>> 		  	- Try auth_sys.
>
> Right now, we use AUTH_SYS if the mount command didn't specify a flavor, 
> but the flavor we're going to use is always checked against the server's 
> returned list.  You seem to be suggesting we should ignore the server's 
> list entirely if sec= was specified...?

Yes.  I can't see what practical problems that would cause.

Also, while I hope this is the last bug in the mountd's flavor list
return, it isn't the first--only recently did we even start using real
information from the export instead of just faking something up.  So I
think it's safest to preserve the historical sec= behavior and give
users a way to override the negotiation, to cut down on bug reports of
mount failures on upgrade.

--b.