src/sys/kgssapi, branch releng/14.3

nfscl/kgssapi: Fix Kerberized NFS mounts to pNFS servers

2023-12-24T01:03:58Z

During recent testing related to the IETF NFSv4 Bakeathon, it was discovered that Kerberized NFSv4.1/4.2 mounts to pNFS servers (sec=krb5[ip],pnfs mount options) was broken. The FreeBSD client was using the "service principal" for the MDS to try and establish a rpcsec_gss credential for a DS, which is incorrect. (A "service principal" looks like "nfs@" and the for the DS is not the same as the MDS for most pNFS servers.) To fix this, the rpcsec_gss code needs to be able to do a reverse DNS lookup of the DS's IP address. A new kgssapi upcall to the gssd(8) daemon is added by this patch to do the reverse DNS along with a new rpcsec_gss function to generate the "service principal". A separate patch to the gssd(8) will be committed, so that this patch will fix the problem. Without the gssd(8) patch, the new upcall fails and current/incorrect behaviour remains. This bug only affects the rare case of a Kerberized (sec=krb5[ip],pnfs) mount using pNFS. This patch changes the internal KAPI between the kgssapi and nfscl modules, but since I did a version bump a few days ago, I will not do one this time. (cherry picked from commit dd7d42a1fae5a4879b62689a165238082421f343)

kgssapi: Add a new file with a function for a future commit

2023-12-24T01:01:11Z

A future commit needs a new upcall function that can do reverse DNS in order to generate a "service principal". This patch adds the file. (cherry picked from commit 428879dc9110240ad0940c7ac8cd69bcaf6e686e)

sys: Remove $FreeBSD$: one-line sh pattern

2023-08-16T17:54:58Z

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

sys: Remove $FreeBSD$: one-line .c pattern

2023-08-16T17:54:36Z

Remove /^[\s*]*__FBSDID$"\$FreeBSD\$"$;?\s*\n/

sys: Remove $FreeBSD$: one-line .c comment pattern

2023-08-16T17:54:24Z

Remove /^/[*/]\s*\$FreeBSD\$.*\n/

sys: Remove $FreeBSD$: two-line .h pattern

2023-08-16T17:54:11Z

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

2023-05-12T16:44:03Z

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix

nfsd: Enable the NFSD_VNET vnet front end macros

2023-02-18T22:59:36Z

Several commits have added front end macros for the vnet macros to the NFS server, krpc and kgssapi. These macros are now null, but this patch changes them to front end the vnet macros. With this commit, many global variables in the code become vnet'd, so that nfsd(8), nfsuserd(8), rpc.tlsservd(8) and gssd(8) can run in a vnet prison, once enabled. To run the NFS server in a vnet prison still requires a couple of patches (in D37741 and D38371) that allow mountd(8) to export file systems from within a vnet prison. Once these are committed to main, a small patch to kern_jail.c allowing "allow.nfsd" without VNET_NFSD defined will allow the NFS server to run in a vnet prison. One area that still needs to be settled is cleanup when a prison is removed. Without this, everything should work except there will be a leak of malloc'd data and mutex locks when a vnet prison is removed. MFC after: 3 months

kgssapi: Add macros so that gssd(8) can run in vnet prison

2023-02-15T23:18:46Z

Commit 7344856e3a6d added a lot of macros that will front end vnet macros so that nfsd(8) can run in vnet prison. This patch adds similar macros named KGSS_VNETxxx so that the gssd(8) daemon can run in a vnet prison, once the macros front end the vnet ones. For now, they are null macros. This is the last commit that adds macros. The next step is to change the macros to front end the vnet ones. MFC after: 3 months

kgssapi: Increase timeout for kernel to gssd(8) upcalls

2023-01-11T21:20:31Z

It turns out that the underlying problem that caused a Kerberized NFS mount with the "gssname" option to fail was that the kernel upcall to the gssd(8) daemon would time out prematurely after 25 seconds. The gss_acquire_cred() GSSAPI library call takes about 27 seconds for the case where a desired_name argument is specified. A similarly long delay occurs when the gss_init_sec_context() call is made and the user principal's TGT has expired. Once the upcall timed out, the kernel code assumed that the gssd(8) daemon had died and closed the socket. Ironically, closing the socket did cause the gssd(8) daemon to terminate via a SIGPIPE signal. This patch increases the timeout to 5 minutes. Since a timeout should only occur when the gssd(8) daemon has died, a long timeout should be ok and seems to fix this problem. I still think that commit c33509d49a should remain in the system, since it allows the mount to complete quickly and not take nearly 30 seconds. PR: 268823 MFC after: 2 weeks