Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > muc.lists.netbsd.tech.kern > #23525

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

From od2uvb@0w.se
Newsgroups muc.lists.netbsd.tech.kern
Subject regarding support of NFS versions (Re: Changing NGROUPS_MAX to 1024?)
Date 2026-04-20 08:41 +0200
Organization Newsgate at muc.de e.V.
Message-ID <aeXKk-cYENGuSa2J@localhost> (permalink)
References <> <202604191353.JAA04942@Stone.Rodents-Montreal.ORG>

Show all headers | View raw


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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

Back to muc.lists.netbsd.tech.kern | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Changing NGROUPS_MAX to 1024? Mouse <mouse@Rodents-Montreal.ORG> - 2026-04-19 09:53 -0400
  NFS security (was: Changing NGROUPS_MAX to 1024?) Edgar Fuß <ef@math.uni-bonn.de> - 2026-04-19 18:54 +0200
  Re: Changing NGROUPS_MAX to 1024? Piotr Meyer <aniou+netbsd@smutek.pl> - 2026-04-19 17:16 +0200
  regarding support of NFS versions (Re: Changing NGROUPS_MAX to 1024?) od2uvb@0w.se - 2026-04-20 08:41 +0200
    Re: regarding support of NFS versions Edgar Fuß <ef@math.uni-bonn.de> - 2026-04-24 17:43 +0200
      Re: regarding support of NFS versions Ken Hornstein <kenh@cmf.nrl.navy.mil> - 2026-04-24 12:07 -0400

csiph-web