> On May 2, 2024, at 11:54 AM, Scott Mayhew <smayhew@xxxxxxxxxx> wrote: > > 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? The problem might be in how you've set up the exports. With NFSv3, the parent export needs the "crossmnt" export option in order for NFSv3 to behave like NFSv4 in this regard, although I could have missed something. > Should > there be an errata to RFC 9289 and a request from IANA for assigned numbers for > pseudo-flavors corresponding to xprtsec policies? No. Transport-layer security is not an RPC security flavor or pseudo-flavor. These two things are not related. (And in fact, I proposed something like this for NFSv4 SECINFO, but it was rejected). > If not, this behavior should at least be documented in the man pages. "crossmnt", and it's kin "nohide", are explained in exports(5). -- Chuck Lever
