lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <170595930799.23031.17998490973211605470@noble.neil.brown.name>
Date: Tue, 23 Jan 2024 08:35:07 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Jeff Layton" <jlayton@...nel.org>
Cc: "Lorenzo Bianconi" <lorenzo@...nel.org>, linux-nfs@...r.kernel.org,
 lorenzo.bianconi@...hat.com, kuba@...nel.org, chuck.lever@...cle.com,
 horms@...nel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v6 3/3] NFSD: add write_ports to netlink command

On Tue, 23 Jan 2024, Jeff Layton wrote:
> On Sat, 2024-01-20 at 18:33 +0100, Lorenzo Bianconi wrote:
> > Introduce write_ports netlink command. For listener-set, userspace is
> > expected to provide a NFS listeners list it wants to enable (all the
> > other ports will be closed).
> > 
> 
> Ditto here. This is a change to a declarative interface, which I think
> is a better way to handle this, but we should be aware of the change.

I agree it is better, and thanks for highlighting the change.

> > +	/* 2- remove stale listeners */
> 
> 
> The old portlist interface was weird, in that it was only additive. You
> couldn't use it to close a listening socket (AFAICT). We may be able to
> support that now with this interface, but we'll need to test that case
> carefully.

Do we ever want/need to remove listening sockets?
Normal practice when making any changes is to stop and restart where
"stop" removes all sockets, unexports all filesystems, disables all
versions.
I don't exactly object to supporting fine-grained changes, but I suspect
anything that is not used by normal service start will hardly ever be
used in practice, so will not be tested.

So if it is easiest to support reverting previous configuration (as it
probably is for version setting), then do so.  But if there is any
complexity (as maybe there is with listening sockets), then don't
add complexity that won't be used.

Thanks,
NeilBrown

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ