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
