Re: mount.nfs: access denied by server

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

Trond Myklebust wrote:
> On Tue, 2009-08-25 at 14:39 -0400, Trond Myklebust wrote:
>   
>> On Tue, 2009-08-25 at 13:17 -0500, Tom Haynes wrote:
>>     
>>> Trond Myklebust wrote:
>>>       
>>>> On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
>>>>   
>>>>         
>>>>> With OpenSolaris NFSv3, there is no autonegotiation.  With NFSv4, we 
>>>>> support the autonegotiation
>>>>> as defined in the protocol.
>>>>>
>>>>> We just went through a regression with this algorithm.
>>>>>     
>>>>>           
>>>> NFSv4 also allows the server to change the list of supported security
>>>> flavours on the fly at any point in the namespace, and at any time. How
>>>> does OpenSolaris currently deal with this?
>>>>
>>>>   
>>>>         
>>> The client gets a WRONGSEC and then initiates auto-negotiation.
>>>
>>>       
>> Right, but are there any limits to that?
>>
>> Will it, for instance, allow process 1 to continue using auth_sys, while
>> process 2 switches to using krb5 on the same file?
>>     

 From *reading* the code,  I think process 1 is fat, dumb, and happy 
until it tries an
action which generates a WRONGSEC. At that point it will have to negotiate.


>> Should it recover in the case where the administrator suddenly removes
>> krb5 from the list, and replaces it with krb5i on all subdirectories
>> of ../../.. relative to your current working directory?
>>     
>
> Sorry. Let me be more specific...
>
> Say you have
>
> /foo sec=krb5,rw
>
> and the administrator adds a new rule
>
> /foo/bar sec=krb5i,rw
>
> Will your autonegotiator be able to recover processes that are working
> in /foo/bar/... without disturbing those working in /foo/baz/... ?
>
>   


I'll let someone who knows the client give the real response, but 
consider two
threads, one in /foo/baz and one in /foo/bar.

The one in /foo/baz will never get a WRONGSEC.

The one in /foo/bar may never get one either - depending on the server 
implementation.
i.e., the server has probably put the FSID in the FH. The client is 
handing back
what is probably a non-volatile FH and the server has to honor it. And 
the server
may have no clue that the FH is under a new mount point.

What happens if the client redrives a LOOKUP of the directory entry? It 
should
discover that the FHs no longer match and do some sort of recovery.






> Cheers
>   Trond
>
>   


Sounds like a great thing to test at the next BAT. :->