Received-SPF: pass (google.com: domain of linux-nfs+bounces-3131-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 2 May 2024 13:37:42 -0400
From: Scott Mayhew <smayhew@redhat.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: NFSv3 and xprtsec policies
Message-ID: <ZjPPZmBZJZVmBuA6@aion>
References: <ZjO3Qwf_G87yNXb2@aion>
 <100A1A35-2B53-46CA-A448-F82A95CA1EFA@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <100A1A35-2B53-46CA-A448-F82A95CA1EFA@oracle.com>

On Thu, 02 May 2024, Chuck Lever III wrote:

>=20
>=20
> > On May 2, 2024, at 11:54=E2=80=AFAM, Scott Mayhew <smayhew@redhat.com> =
wrote:
> >=20
> > Red Hat QE identified an "interesting" issue with NFSv3 and TLS, in tha=
t an
> > NFSv3 client can mount with "xprtsec=3Dnone" a filesystem exported with
> > "xprtsec=3Dtls: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).
> >=20
> > Here's an example using machines from the recent Bakeathon.
> >=20
> > Mounting a server with TLS enabled:
> >=20
> > # mount -o v4.2,sec=3Dsys,xprtsec=3Dtls oracle-102.chuck.lever.oracle.c=
om.nfsv4.dev:/export/tls /mnt
> > # umount /mnt
> >=20
> > Trying to mount without "xprtsec=3Dtls" shows that the filesystem is no=
t exported with "xprtsec=3Dnone":
> >=20
> > # mount -o v4.2,sec=3Dsys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/=
export/tls /mnt
> > mount.nfs: Operation not permitted for oracle-102.chuck.lever.oracle.co=
m.nfsv4.dev:/export/tls on /mnt
> >=20
> > Yet a v3 mount without "xprtsec=3Dtls" works:
> >=20
> > # mount -o v3,sec=3Dsys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/ex=
port/tls /mnt
> > # umount /mnt
> >=20
> > and a mount with no explicit version and without "xprtsec=3Dtls" falls =
back to
> > v3 and also "works":
> >=20
> > # mount -o sec=3Dsys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/expor=
t/tls /mnt
> > # grep ora /proc/mounts
> > oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt nfs
> > +rw,relatime,vers=3D3,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,p=
roto=3Dtcp,timeo=3D600,retrans=3D2,sec=3Dsys,mountaddr=3D100.64.0.49,mountv=
ers=3D3,mountport=3D20048,mountproto=3Dudp,local_lock=3Dnone,addr=3D100.64.=
0.49 0 0
> >=20
> > Even though the filesystem is mounted, the client can't do anything wit=
h it:
> >=20
> > # ls /mnt
> > ls: cannot open directory '/mnt': Permission denied
> >=20
> > When krb5 is used with NFSv3, the server returns a list of pseudoflavor=
s in
> > mountres3_ok (https://datatracker.ietf.org/doc/html/rfc1813#section-5.2=
=2E1).
> > The client compares that list with its own list of auth flavors parsed =
=66rom the
> > mount request and returns -EACCES if no match is found (see
> > nfs_verify_authflavors()).
> >=20
> > Perhaps we should be doing something similar with xprtsec policies?
>=20
> 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.

I was mounting your server though :)
>=20
>=20
> > Should
> > there be an errata to RFC 9289 and a request from IANA for assigned num=
bers for
> > pseudo-flavors corresponding to xprtsec policies?
>=20
> No. Transport-layer security is not an RPC security flavor or
> pseudo-flavor. These two things are not related.
>=20
> (And in fact, I proposed something like this for NFSv4 SECINFO,
> but it was rejected).

I thought it might be a stretch to try to use mountres3.auth_flavors for
this, but since RFC 9289 does refer to AUTH_TLS as an authentication
flavor and https://www.iana.org/assignments/rpc-authentication-numbers/rpc-=
authentication-numbers.xhtml
also lists TLS under the Flavor Name column I thought it might make
sense to treat xprtsec policies as if they were pseudo-flavors even
though they're not, if only to give the client a way to determine that
the mount should fail.

>=20
>=20
> > If not, this behavior should at least be documented in the man pages.
>=20
> "crossmnt", and it's kin "nohide", are explained in exports(5).

rpc.mountd doesn't do any access checking based on xprtsec policies on
the export (or krb5 pseudo-flavors, for that matter), so I don't see how
"crossmount" or "nohide" would have any effect here.

-Scott
>=20
>=20
> --
> Chuck Lever
>=20
>=20