Re: [RFC] RPCBIND: add anonymous listening socket in addition to named one

Stanislav Kinsbursky
2011-12-29T16:13:35Z

29.12.2011 20:03, Chuck Lever пишет:
>> Because unix named (!) sockets are not network namespace aware.
>
> OK, this is the part I was unaware of. Bruce and I had talked about this a few months ago, and my take-away was that these sockets were network namespace-aware, such that this was supposed to work as we want, already.
>
>> They are "current->fs->root" aware.
>
> In other words, these are relative to the local file namespace, not the local network namespace. I was afraid of that.
>
>> I.e. if this connect operation would be performed on "sync mode" (i.e. from the context of mount of NFS server start operation), then all will works fine (in case of each container works in it's own root, of course).
>> But currently all connect operations are done by rpciod_workqueue. I.e. regardless to root of process, started service registration, unix socket will be always looked up by path "/var/run/rpcbind.sock" starting from rpciod_workqueue root. I can set desired root before kernel connect during handling RPC task by rpciod_workqueue and revert back to the old one after connection and this will solve the problem to.
>> But this approach looks like ugly hack to me. And also requires additional pointer in sock_xprt structure to bypass desired context to rpciod_workqueue handler.
>
> Can several network namespaces share the same file namespace? That might cause them to share the same rpcbind, which is undesirable. Might this also be a problem for user space?
>

Yes, they can. But only in general. And it will be a problem for user space
programs, using unix named sockets for network related stuff (like rpcbind, for
instance).
But, actually, I don't see any sense in having several network namespaces with
the same root. Probably someone can suggest a specific "real life" solution,
which can use such scheme. But it's not a container and thus no guarantees
should be provided in this case from my pow.
Or we need to throw away this unix sockets approach and use only network
namespace aware routines. But again, does this really required?