mail.gmail.com> From: Rick Macklem Date: Tue, 28 Jul 2026 18:33:06 -0700 X-Gm-Features: AUfX_mximSFz2TOSiNZ8sJZ6KcfwgUL8DnmPxux7X6yubltxXOdKtK3gKE6YTiY Message-ID: Subject: Re: rfe: NFS resvport/noresvport per-export options To: Lionel Cons Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.90 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.904]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from] X-Rspamd-Queue-Id: 4h8vwz17zXz3vF2 X-Spamd-Bar: ---- On Sat, Jul 25, 2026 at 10:06=E2=80=AFAM Lionel Cons wrote: > > On Mon, 15 Jun 2026 at 10:11, Lionel Cons wrot= e: > > > > 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 >=3D 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=3D296550 for th= is. 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 stude= nts 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 neve= r 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 >