Hi Jeff, There doesn't need to be anything done by the administrators (not for the linux implementation). The negotiation is specified in the spec. In the EXCHANGE_ID the client has a eia_state_protection field which it sets to SP4_MACH_CREDS and provides 2 lists must_enforce and must_allow (here's the spec): "The second list is spo_must_allow and consists of those operations the client wants to have the option of sending with the machine credential or the SSV-based credential, even if the object the operations are performed on is not owned by the machine or SSV credential. The corresponding result, also called spo_must_allow, consists of the operations the server will allow the client to use SP4_SSV or SP4_MACH_CRED credentials with. Normally, the server's result equals the client's argument, but the result MAY be different. The purpose of spo_must_allow is to allow clients to solve the following conundrum. Suppose the client ID is confirmed with EXCHGID4_FLAG_BIND_PRINC_STATEID, and it calls OPEN with the RPCSEC_GSS credentials of a normal user. Now suppose the user's credentials expire, and cannot be renewed (e.g., a Kerberos ticket granting ticket expires, and the user has logged off and will not be acquiring a new ticket granting ticket). The client will be unable to send CLOSE without the user's credentials, which is to say the client has to either leave the state on the server or re-send EXCHANGE_ID with a new verifier to clear all state, that is, unless the client includes CLOSE on the list of operations in spo_must_allow and the server agrees." It's possible that the NAS storage didn't allow for the CLOSE to be done with the machine creds and thus without user creds the state would be left open on the server. I suggest you capture a network trace during a mount and check the content of the reply. On Tue, Jan 31, 2023 at 6:08 PM Andrew J. Romero <romero@xxxxxxxx> wrote: > > Hi Olga > > Based on Jeff's post > > Are there some NFS-client side flags that need to be set by > the sys-admins to have the state-operations performed > by the machine credential ? > > Are there any server-side requirements that must be fulfilled > so that the correct behavior is negotiated between client and server ? > > What versions of the client ( RHEL-7 , 8 ..) support this behavior > ( state-ops performed by machine credential ) > > What versions of NFS ( 4.0, 4.1 .... ) support / mandate this behavior > > Thanks Again > > If any of you plan on visiting Illinois soon, I owe you lunch ! > > Andy > > > > > > Here's the paragraph of the spec stating that things like CLOSE must be allowed: > > > > In cases where the server's security policies on a portion of its > > namespace require RPCSEC_GSS authentication, a client may have to use > > an RPCSEC_GSS credential to remove per-file state (e.g., LOCKU, CLOSE, > > etc.). The server may require that the principal that removes the > > state match certain criteria (e.g., the principal might have to be the > > same as the one that acquired the state). However, the client might > > not have an RPCSEC_GSS context for such a principal, and might not be > > able to create such a context (perhaps because the user has logged > > off). When the client establishes SP4_MACH_CRED or SP4_SSV protection, > > it can specify a list of operations that the server MUST allow using > > the machine credential (if SP4_MACH_CRED is used) or the SSV > > credential (if SP4_SSV is used). > > > > If the NAS vendor is disallowing it then they are in the wrong. > >
