regarding support of NFS versions (Re: Changing NGROUPS_MAX to 1024?)

[od2uvb%0w.se@localhost]

On Sun, Apr 19, 2026 at 09:53:48AM -0400, Mouse wrote:
> > [...] NFSv3 itself and the security workarounds come with a cost (not
> > least the inevitable constraints on the system's management and
> > evolution/adjustment).
> 
> Yes, but...
> 
> > Relying on some mainstream OS with support for NFSv4 does not bring
> > similar disadvantages.
> 
> ...doesn't it?  In my experience, *every* OS, including "mainstream"
> ones, comes with its own constraints on system mangement, evolution,
> and adjustment.  It's a question of tradeoffs: which set of constraints
> is less of a problem for the use case in question?

Those constraints are there with or without NFS, on NetBSD or otherwise.

NFS3 adds to them an inferior security model and forces administration
of all the clients to be tightly synchronized with the server(s).

> My feeling - deriving largely from my experience - is that NFS
> is far more likely to be deployed in a private internal network than
> over relatively attackable networks like the open Internet.  Do you
> have reason to think that feeling is wrong in the large, that "new NFS
> installations" predominantly have threat models where on-the-wire
> attacks are significant enough for them to find NFSv3 unacceptable?

To allow a compromise of a single unit attached to a "protected network"
to make most of the data accessible? It makes sense, when the value of
the data is so low that no attacker would ever care, or when the network
is really small and under total control.
This excludes any large/heterogeneous installation with nontrivial data.

(yes, adding Kerberos to NFSv3 would improve this, but would leave its
other limitations in place)

> (Honestly, my guess would be that most of them have not even formulated
> their threat model.)

Sadly, at least some of them.

Fortunately, there are also users and system designers who try to
do better.

regards,
od2uvb