Red Hat QE identified an "interesting" issue with NFSv3 and TLS, in that an NFSv3 client can mount with "xprtsec=none" a filesystem exported with "xprtsec=tls:mtls" (in the sense that the client gets the filehandle and adds a mount to its mount table - it can't actually access the mount). Here's an example using machines from the recent Bakeathon. Mounting a server with TLS enabled: # mount -o v4.2,sec=sys,xprtsec=tls oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt # umount /mnt Trying to mount without "xprtsec=tls" shows that the filesystem is not exported with "xprtsec=none": # mount -o v4.2,sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt mount.nfs: Operation not permitted for oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls on /mnt Yet a v3 mount without "xprtsec=tls" works: # mount -o v3,sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt # umount /mnt and a mount with no explicit version and without "xprtsec=tls" falls back to v3 and also "works": # mount -o sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt # grep ora /proc/mounts oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt nfs +rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=100.64.0.49,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=100.64.0.49 0 0 Even though the filesystem is mounted, the client can't do anything with it: # ls /mnt ls: cannot open directory '/mnt': Permission denied When krb5 is used with NFSv3, the server returns a list of pseudoflavors in mountres3_ok (https://datatracker.ietf.org/doc/html/rfc1813#section-5.2.1). The client compares that list with its own list of auth flavors parsed from the mount request and returns -EACCES if no match is found (see nfs_verify_authflavors()). Perhaps we should be doing something similar with xprtsec policies? Should there be an errata to RFC 9289 and a request from IANA for assigned numbers for pseudo-flavors corresponding to xprtsec policies? If not, this behavior should at least be documented in the man pages. -Scott
