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