Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <81826e4f-aa4c-1213-8b2e-28ef57caf1a3@cogentembedded.com>
Date:   Mon, 8 May 2023 08:50:29 +0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH 1/1] nfslock01.sh: Don't test on NFS v3 on TCP
Content-Language: en-US
To:     Petr Vorel <pvorel@suse.cz>, Jeff Layton <jlayton@kernel.org>
Cc:     ltp@lists.linux.it, NeilBrown <neilb@suse.de>,
        Cyril Hrubis <chrubis@suse.cz>, linux-nfs@vger.kernel.org,
        Steve Dickson <steved@redhat.com>,
        Alexey Kodanev <aleksei.kodanev@bell-sw.com>
References: <20230502075921.3614794-1-pvorel@suse.cz>
 <d441b9f9dfcbb4719d97c7b3b5950dfeeb8913d2.camel@kernel.org>
 <20230502134146.GA3654451@pevik>
From:   Nikita Yushchenko <nikita.yoush@cogentembedded.com>
In-Reply-To: <20230502134146.GA3654451@pevik>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

>> rpcbind was obviously written in a time before namespaces were even a
>> thought to anyone. I wonder if there is something we can do in rpcbind
>> itself to guard against these sorts of shenanigans? Probably not, I
>> guess...
> 
> Maybe Steve or Neil have some idea.
> 
>> Is /var shared between namespaces in this test for some particular
>> reason?
> 
> I hope I got , we talk about /var/run/netns/ltp_ns, which is symlink to
> /proc/$pid/ns/net. Or is it really about /run/rpcbind.sock vs
> /var/run/rpcbind.sock?

The overall picture is:

- by design, filesystem namespaces and network namespaces are independent, it is pretty ok for two 
processes to share filesystem namespace and be in different network namespaces, or vice versa.

- the code in question, while being in the kernel for ages, is breaking this basic design, by using 
filesystem path to contact a network service,

- thus the fix is: just not do that.

I consider kernel contacting rpcbind via AF_UNIX being a bug in the kernel namespace implementation. So 
this is a rare case when a test suite (LTP) helped to find a non-obvious kernel bug. Just need to fix 
that bug, if not yet.

Rpcbind listens both via AF_INET and via AP_UNIX, and did so for ages.
It is even not possible to disable AF_INET listening without patching code. By stopping contacting it 
via AF_UNIX, it is virtually impossible to break anything.

Nikita