Re: rfe: NFS resvport/noresvport per-export options

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
>