Date: Tue, 28 Jul 2026 18:33:06 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Lionel Cons <lionelcons1972@gmail.com> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org> Subject: Re: rfe: NFS resvport/noresvport per-export options Message-ID: <CAM5tNy4qUdOxPEns2nSnC=Z9A872Q2QmQHMSQHUZ2nu9TQTZMg@mail.gmail.com>
index | next in thread | raw e-mail
On Sat, Jul 25, 2026 at 10:06 AM Lionel Cons <lionelcons1972@gmail.com> wrote: > > On Mon, 15 Jun 2026 at 10:11, Lionel Cons <lionelcons1972@gmail.com> wrote: > > > > Followup thread to "ms-nfs41-client mount to FreeBSD 16.0 nfsd fails > > in VM with NAT" > > > > I would be preferable to have a resvport (and noresvport) export > > option on a per-export basis to choose whether mounts from UDP/TCP > > ports >= 1024 are allowed or not, overriding any kernel default. > > > > While it is desired to keep the current default, it might be useful to > > allow UDP/TCP ports on a per-export basis to make access from systems > > behind NAT (e.g. VMs) easier. > > > > This mirrors the same "resvport" export option as found in > > Solaris/Illumos, and the "insecure" export option as found in Linux. > > I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296550 for this. Yes, I've seen this. I was hoping others would comment, but they have not, so here goes.. Long, long ago, I administered 4BSD timesharing systems where I tried fairly hard to ensure "root" was secure on them, but they had lots of students logging into them. As such, they had the property: - Trusted machine, trusted root on machine, untrusted users --> For this case (but for few, if any, others), requiring a reserved port# for an NFSv2 (and later NFSv3) mount made sense (since only "root" could get a reserved port# on the client end). Note that NFSv2/v3 are simple, stateless server protocols, where every RPC request has a file handle in it and every server file system is mounted separately. --> As such, having a "per server file system export controlling whether or not a reserved port# is required" made sense. (Although it was never done for FreeBSD, afaik.) Now, things are quite different.. - How many system are there out there, where (A) or something similar applies, such that requiring a reserved port# makes sense? - For NFSv4, the protocol is stateful, which means many operations do not use a file handle and, therefore, are not associated with any file system. (Allowing those to be done with a non-reserved port# means a malicious user can Dos or trash the Open/Lock state of the server. As such, controlling whether or not a reserved port# is required, based on file system limits any restriction for file access. --> Even weaker than requiring a reserved port# for all acces, which is what can currently be done for FreeBSD. Also, for NFSv4, the exports are a tree of file systems unlike NFSv3, which exports individual file systems. Image this layout: - 2 exported file systems /reserved-port and /non-reserved-port - The NFSv4 exported tree would have both. - Now a client mounts without a reserved port# and does "ls -l" on "/". I suppose the reply should only show "/non-reserved-port", but implementing that is non-trivial. As such, I don't see mixing "requires reserved port#" and "doesn't require a reserved port#" file systems for the NFSv4 exports as a practical thing. (You should grab a Linux or Solaris server and try mixing them and see how it goes when NFSv4 mounted from a client that does not use a reserved port#.) I am very busy with other stuff I find more interesting, so, I, personally, am not interested in working on this. Others are welcome to come up with a patch. rick > > Lionel >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy4qUdOxPEns2nSnC=Z9A872Q2QmQHMSQHUZ2nu9TQTZMg>