src/sys/fs/nfsserver, branch stable/13

nfs, rpc: Ensure kernel credentials have at least one group

2024-11-15T12:59:09Z

This fixes several bugs where some 'struct ucred' in the kernel, constructed from user input (via nmount(2)) or obtained from other servers (e.g., gssd(8)), could have an unfilled 'cr_groups' field and whose 'cr_groups[0]' (or 'cr_gid', which is an alias) was later accessed, causing an uninitialized access giving random access rights. Use crsetgroups_fallback() to enforce a fallback group when possible. For NFS, the chosen fallback group is that of the NFS server in the current VNET (NFSD_VNET(nfsrv_defaultgid)). There does not seem to be any sensible fallback available in rpc code (sys/rpc/svc_auth.c, svc_getcred()) on AUTH_UNIX (TLS or not), so just fail credential retrieval there. Stock NSS sources, rpc.tlsservd(8) or rpc.tlsclntd(8) provide non-empty group lists, so will not be impacted. Discussed with: rmacklem (by mail) Approved by: markj (mentor) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D46918 (cherry picked from commit cfbe7a62dc62e8a5d7520cb5eb8ad7c4a9418e26) Approved by: markj (mentor)

nfsd: Fix handling of credentials with cr_ngroups == 0

2024-10-24T01:13:24Z

There has been a documented case in the exports(5) man page forever, which specifies that the -maproot or -mapall may have a single user entry, followed by a ':'. This case is defined as specifying no groups (aka cr_ngroups == 0). This patch fixes the NFS server so that it handles this case correctly. After MFC'ng this patch to stable/13 and stable/14, I propose that this unusual case be deprecated and no longer allowed in FreeBSD15. At that point, this patch can be reverted. (cherry picked from commit caa309c8811d62a24cd07e3a1f6e9095eaf10c90)

nfsd: Fix close handling when vfs.nfsd.enable_locallocks=1

2024-10-12T00:49:55Z

nfsrv_freeopen() was being called after the mutex lock was released, making it possible for other kernel threads to change the lists while nfsrv_freeopen() took the nfsstateid out of the lists. This patch moves the code around "if (nfsrv_freeopen(stp, vp, 1 p) == 0) {" into nfsrv_freeopen(), so that it can remove the nfsstateid structure from all lists before unlocking the mutex. This should avoid any race between CLOSE and other nfsd threads updating the NFSv4 state. The patch does not affect semantics when vfs.nfsd.enable_locallocks=0. PR: 280978 Tested by: Matthew L. Dailey (cherry picked from commit eb345e05ac6602eeef0c33fce9025bbc8ec44d0f)

nfsd: Fix handling of NFSv4 setable attributes

2024-09-10T01:37:24Z

Commit d8a5961 made a change to nfsv4_sattr() that broke parsing of the setable attributes for a NFSv4 SETATTR. (It broke out of the code by setting "error" and returning right away, instead of noting the error in nd_repstat and allowing parsing of the attributes to continue.) By returning prematurely, it was possible for SETATTR to return the error, but with a bogus set of attribute bits set, since "retbits" had not yet been set to all zeros. (I am not sure if any client could be affected by this bug. The patch was done for a failure case detected by a pynfs test suite and not an actual client.) While here, the patch also fixes a few cases where the value of attributes gets set for attributes after an error has been set in nd_repstat. This would not really break the protocol, since a SETATTR is allowed to set some attributes and still return an failure, but should not really be done. (cherry picked from commit 5037c6398b2327366494a0434a894dc17ba8d023)

nfsd: Make modifying vfs.nfsd.enable_locallocks safe

2024-07-23T00:35:02Z

Commit dfaeeacc2cc2 modified clientID handling so that it could be done with only a mutex lock held when vfs.nfsd.enable_locallocks is 0. This makes it unsafe to change the setting of vfs.nfsd.enable_locallocks when nfsd threads are active. This patch forces all nfsd threads to be blocked when the value of vfs.nfsd.enable_locallocks is changed, so that it is done safely. (cherry picked from commit 67284d32e5e0d5f015d73eeac4342974277263f5)

nfsd: Allow a mutex lock for clientID handling

2024-07-22T22:18:16Z

On Feb. 28, a problem was reported on freebsd-stable@ where a nfsd thread processing an ExchangeID operation was blocked for a long time by another nfsd thread performing a copy_file_range. This occurred because the copy_file_range was taking a long time, but also because handling a clientID requires that all other nfsd threads be blocked via an exclusive lock, as required by ExchangeID. This patch allows clientID handling to be done with only a mutex held (instead of an exclusive lock that blocks all other nfsd threads) when vfs.nfsd.enable_locallocks is 0. For the case of vfs.nfsd.enable_locallocks set to 1, the exclusive lock that blocks all nfsd threads is still required. This patch does make changing the value of vfs.nfsd.enable_locallocks somewhat racy. A future commit will ensure any change is done when all nfsd threads are blocked to avoid this racyness. (cherry picked from commit dfaeeacc2cc29d0497ecd4cd5b7fd0d5ab61fcd5)

nfsd: Fix nfsrv_cleanclient so that it can be called with a mutex

2024-07-21T23:30:11Z

On Feb. 28, a problem was reported on freebsd-stable@ where a nfsd thread processing an ExchangeID operation was blocked for a long time by another nfsd thread performing a copy_file_range. This occurred because the copy_file_range was taking a long time, but also because handling a clientID requires that all other nfsd threads be blocked via an exclusive lock, as required by ExchangeID. This patch adds two arguments to nfsv4_cleanclient() so that it can optionally be called with a mutex held. For this patch, the first of these arguments is "false" and, as such, there is no change in semantics. However, this change will allow a future commit to modify handling of the clientID so that it can be done with a mutex held while other nfsd threads continue to process NFS RPCs. (cherry picked from commit a7de51068502ad1e2851d4a855ed28b27573bb36)

nfsd: Fix Link conformance with RFC8881 for delegations

2024-05-11T01:09:21Z

RFC8881 specifies that, when a Link operation occurs on an NFSv4, that file delegations issued to other clients must be recalled. Discovered during a recent discussion on nfsv4@ietf.org. Although I have not observed a problem caused by not doing the required delegation recall, it is definitely required by the RFC, so this patch makes the server do the recall. Tested during a recent NFSv4 IETF Bakeathon event. (cherry picked from commit 3f65000b6b1460a7a23cd83014bb41a68d1a8a19)

Revert "nfsd: Fix NFSv4.1/4.2 Claim_Deleg_Cur_FH"

2024-04-28T01:41:12Z

This reverts commit f300335d9aebf2e99862bf783978bd44ede23550. It turns out that the old code was correct and it was wireshark that was broken and indicated that the RPC's XDR was bogus. Found during IETF bakeathon testing this week. (cherry picked from commit 54c3aa02e926268ba5551cd7d28fddf38b3589a2)

nfsd: Add a sysctl to limit NFSv4.2 Copy RPC size

2024-03-30T01:05:31Z

NFSv4.2 supports a Copy operation, which avoids file data being read to the client and then written back to the server, if both input and output files are on the same NFSv4.2 mount for copy_file_range(2). Unfortunately, this Copy operation can take a long time under certain circumstances. If this occurs concurrently with a RPC that requires an exclusive lock on the nfsd such as ExchangeID done for a new mount, the result can be an nfsd "stall" until the Copy completes. This patch adds a sysctl that can be set to limit the size of a Copy operation or, if set to 0, disable Copy operations. The use of this sysctl and other ways to avoid Copy operations taking too long will be documented in the nfsd.4 man page by a separate commit. (cherry picked from commit 748f56c53f4286e0b140c1b779ff8ade1cf4fec9)