Re: mount.nfs: access denied by server

[Tom Haynes <Thomas.Haynes-UdXhSnd/wVw@public.gmane.org>]

Chuck Lever wrote:
> On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote:
>> Sent from my iPhone
>>
>> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org> 
>> 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.
>>>
>>
>> Which is pretty much what we do. The exception being that the default 
>> flavor is a setting - and probably always AUTH_SYS...
>
> I'm still not sure what is the right thing to do here.  Looking at 
> 1813, it says:

Sorry, I read this wrong, I thought the question was how should the 
client handle
security flavors from the mount command.

With respect to the server returning a list, our implementation does 
look at the list
of returned flavors and only tries to use one in the list. That was 
actually the fix that
Bruce just applied - the linux server was returning an empty list and 
the OpenSolaris
server would fail the mount.