netdev - Re: [PATCH v6 3/3] NFSD: add write

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]

Date: Fri, 26 Jan 2024 02:38:49 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Neil Brown <neilb@...e.de>
CC: Jeff Layton <jlayton@...nel.org>, Lorenzo Bianconi <lorenzo@...nel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Lorenzo Bianconi
	<lorenzo.bianconi@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>, Simon Horman
	<horms@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>
Subject: Re: [PATCH v6 3/3] NFSD: add write_ports to netlink command



> On Jan 25, 2024, at 5:44 PM, NeilBrown <neilb@...e.de> wrote:
> 
> On Thu, 25 Jan 2024, Chuck Lever III wrote:
>> 
>> 
>>> On Jan 24, 2024, at 6:24 AM, Jeff Layton <jlayton@...nel.org> wrote:
>>> 
>>> On Wed, 2024-01-24 at 10:52 +0100, Lorenzo Bianconi wrote:
>>>> [...]
>>>>> 
>>>>> That's a great question. We do need to properly support the -H option to
>>>>> rpc.nfsd. What we do today is look up the hostname or address using
>>>>> getaddrinfo, and then open a listening socket for that address and then
>>>>> pass that fd down to the kernel, which I think then takes the socket and
>>>>> sticks it on sv_permsocks.
>>>>> 
>>>>> All of that seems a bit klunky. Ideally, I'd say the best thing would be
>>>>> to allow userland to pass the sockaddr we look up directly via netlink,
>>>>> and then let the kernel open the socket. That will probably mean
>>>>> refactoring some of the svc_xprt_create machinery to take a sockaddr,
>>>>> but I don't think it looks too hard to do.
>>>> 
>>>> Do we already have a specific use case for it? I think we can even add it
>>>> later when we have a defined use case for it on top of the current series.
>>>> 
>>> 
>>> Yes:
>>> 
>>> rpc.nfsd -H makes nfsd listen on a particular address and port. By
>>> passing down the sockaddr instead of an already-opened socket
>>> descriptor, we can achieve the goal without having to open sockets in
>>> userland.
>> 
>> Tearing down a listener that was created that way would be a
>> use case for:
> 
> Only if it was actually useful.
> Have you *ever* wanted to do that?  Or heard from anyone else who did?

Container shutdown will want to clear out any listener
that might have been created during the container's
lifetime. How is that done today? Is that simply handled
by net namespace tear-down?


>>> 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.
>> 
>> 
>> 
>> --
>> Chuck Lever


--
Chuck Lever