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,
Not just in the kernel, but also in user-space. The kernel contacts
rpcbind to find how to talk to statd. statd talks to rpcbind to tell it
how it where it can be reached.
AFAIR the badness happens when in-kernel nfsd registers itself in rpcbind, using AF_LOCAL to contact it.
When nfsd is started for a child network namespace, it immediately breaks nfsd running in the root
network namespace, because ports used by the later get overwritten inside rpcbind and become no longer
available for local or remote clients.
I'd say it is userspace responsibility to make entire setup consistent against the used namespaces, but
it is kernel responsibility to keep namespaces isolation while executing individual operations. In the
case of registering in-kernel nfsd being started, using namespace-safe way to do it looks more important
for me than the reasoning outlined in commit 7402ab19cdd5 ("SUNRPC: Use AF_LOCAL for rpcbind upcalls")
that you mention.
And, this won't be fixed by trying to an abstract AF_LOCAL socket before using a filepath-bound one,
since if one is not available, the nfsd running in the root namespace will still get broken by starting
nfsd in a child namespace.
Maybe, the way used to reach rpcbind to register in-kernel services shall be special cased.
Nikita
