On Mon, Nov 15, 2021 at 09:35:51PM +0200, Volodymyr Khomenko wrote: > > Does the spec require that? > > Unfortunately the spec is not explicit about this use-case. > However we have a detailed rationale of the 'spo_must_allow' option there. > It says that 'The client will be unable to send CLOSE without the > user's credentials' if users GSS credentials are expired. > Meaning that AUTH_UNIX credentials (with user UID/GID) is not a valid > way to solve this issue - from my understanding: See the discussion of EXCHGID4_FLAG_BIND_PRINC_STATEID: https://datatracker.ietf.org/doc/html/rfc5661#page-502 When EXCHGID4_FLAG_BIND_PRINC_STATEID is set, the client indicates that it wants the server to bind the stateid to the principal. This means that when a principal creates a stateid, it has to be the one to use the stateid. So that's what's forcing the use of GSS in this case. The OPEN that created the used a certain GSS principal, so the CLOSE would normally have to as well; spo_must_allow gives the client an out in this case. It's not meant to imply that GSS must be used for all operations whenever state protection is used. --b. > > > rfc5661: > > > 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. > > volodymyr. > > On Mon, Nov 15, 2021 at 5:50 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Mon, Nov 15, 2021 at 04:37:10PM +0200, Volodymyr Khomenko wrote: > > > Hello linux-nfs, > > > > > > We have the following NFS4 test (implemented using pynfs framework, > > > not regular NFS4 client): > > > 1. NFS4 client wants to use RPCGSS (Kerberos) and starts NFS4 traffic > > > with NFS4 NULL request to establish RPCGSS context of a machine > > > account. > > > 2. During EXCHANGE_ID operation (client establishment), client asks > > > for SP4_MACH_CRED state protection with > > > spo_must_enforce/spo_must_allow fields set to values that are usually > > > used by NFS4 clients (as defined by rfc5661). > > > 3. CREATE_SESSION and RECLAIM_COMPLETE operations (required for NFS4 > > > session) are also done with RPCGSS and sevice=svc_gss_integrity - as > > > required by spo_must_enforce option of state protection. If > > > CREATE_SESSION is done with the wrong protection type, error is > > > returned to the client (as expected). > > > 4. However, when operations that are neither in spo_must_enforce nor > > > in spo_must_allow list are done with the wrong protection type > > > (flavor=AUTH_UNIX), NFS server accepts the request and replies by > > > unexpected result (NFS4_OK) instead of error. In our test we used > > > SEQUENCE + PUTROOTFH + GETFH compound operation with RPC credentials > > > using flavor=AUTH_UNIX instead of RPCGSS. > > > > > > As for me, it looks like a security issue: client asked for state > > > protection but man-in-the-middle can make unprotected requests for > > > state-protected client and session. Expected behaviour from my side > > > is: > > > if NFS4 operation (like GETFH) from state-protected client is neither > > > in spo_must_enforce nor in spo_must_allow lists of SP4_MACH_CRED, the > > > server must fail the request if used credentials has a different > > > flavor than RPCGSS (neither user GSS context nor machine account GSS > > > context). > > > > There are two separate questions here: > > > > - Does the spec require that? > > - Should the server do it anyway? > > > > I think the answer to the first question is "no". If the requirement is > > in the language you've quoted below, I'm not seeing it. As far as I can > > tell, GSS is required only for operations in spo_must_enforce. > > > > I haven't thought about #2 very much. If an operation's not in > > spo_must_support, I think the server just checks the sec= option on the > > export. If we were to require something more than that, I guess that > > would affect the values returned from SECINFO and friends too. > > > > I think the spec's meant to allow the client to use a combination of > > krb5 and sys, and that current server behavior is correct, though it's > > always possible there's some case I haven't thought through. > > > > --b. > > > > > > > > >From rfc5661 (18.35.3. DESCRIPTION): > > > > > > o For SP4_MACH_CRED or SP4_SSV state protection: > > > > > > * The list of operations (spo_must_enforce) that MUST use the > > > specified state protection. This list comes from the results > > > of EXCHANGE_ID. > > > > > > * The list of operations (spo_must_allow) that MAY use the > > > specified state protection. This list comes from the results > > > of EXCHANGE_ID. > > > > > > ... > > > > > > o SP4_MACH_CRED. If spa_how is SP4_MACH_CRED, then the client MUST > > > send the EXCHANGE_ID request with RPCSEC_GSS as the security > > > flavor, and with a service of RPC_GSS_SVC_INTEGRITY or > > > RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the > > > client wants to use an RPCSEC_GSS-based machine credential to > > > protect its state. The server MUST note the principal the > > > EXCHANGE_ID operation was sent with, and the GSS mechanism used. > > > These notes collectively comprise the machine credential. > > > > > > Please see pcap file of the traffic (attached) - EXCHANGE_ID with > > > SP4_MACH_CRED is the packet #41 and problematic PUTROOTFH + GETFH > > > request is the packet #49. > > > > > > User linux NFS4 server was: > > > [centos@rnd-nfs4-srv01 ~]$ uname -a > > > Linux rnd-nfs4-srv01 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 > > > 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > > > [centos@rnd-nfs4-srv01 ~]$ cat /etc/redhat-release > > > CentOS Linux release 7.7.1908 (Core) > > > >
