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

[Stanislav Kinsbursky <skinsbursky@parallels.com>]

28.12.2011 21:03, Chuck Lever пишет:
>
> On Dec 28, 2011, at 10:17 AM, Stanislav Kinsbursky wrote:
>
> > Hello.
> > I've experienced a problem with registering Lockd service with rpcbind in 
> container. My container operates in it's own network namespace context and has 
> it's own root. But on service register, kernel tries to connect to named unix 
> socket by using rpciod_workqueue. Thus any connect is done with the same 
> fs->root, and this leads to that kernel socket, used for registering service 
> with local portmapper, will always connect to the same user-space socket 
> regardless to fs->root of process, requested register operation.
> > Possible solution for this problem, which I would like to discuss, is to add 
> one more listening socket to rpcbind process. But this one should be 
> anonymous. Anonymous unix sockets accept connections only within it's network 
> namespace context, so kernel socket connect will be done always to the 
> user-space socket in the same network namespace.
>
> A UNIX socket is used so that rpcbind can record the identity of the process 
> on the other end of the socket.  That way only that user may unregister this 
> service.  That user is known as the registration's "owner."  Whatever solution 
> is chosen, I believe we need to preserve the registration owner functionality.
>

Sorry, but I don't get get it.
What do you mean by "user" and "identity"?

> > Does anyone have any objections to this? Or, probably, better solution for 
> the problem?
>
>
> Isn't this also an issue for TCP connections to other hosts?  How does the 
> kernel RPC client choose a TCP connection's source address?
>

I'm confused here too. What TPC connections are you talking about? And what 
source address?

I little bit more info about the whole "NFS in container" structure (as I see it):
1) Each container operates in it's own network namespace and has it's own root.
2) Each contatiner has it's own network device(s) and IP address(es).
3) Each container has it's own rpcbind process instance.
4) Each service (like LockD and NFSd  in future) will register itself with all 
per-net rpcbind instances it have to.

-- 
Best regards,
Stanislav Kinsbursky