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