On Mon, Aug 13, 2012 at 09:39:53PM +0400, Stanislav Kinsbursky wrote:13.08.2012 20:47, J. Bruce Fields ÐÐÑÐÑ:On Sat, Aug 11, 2012 at 03:15:24PM +0400, Stanislav Kinsbursky wrote:11.08.2012 10:23, Pavel Emelyanov ÐÐÑÐÑ:I don't understand--the rpcbind sockets are created by the kernel. WhatOn 08/11/2012 03:09 AM, H. Peter Anvin wrote:I have to notice, that it's not enough and doesn't solve the issue.On 08/10/2012 12:28 PM, Alan Cox wrote:I vote for this (openat + O_WHATEVER on a unix socket) as well. ItExplicitly for Linux yes - this is not generally true of theYes, but let's worry about what the Linux behavior should be.
AF_UNIX socket domain and even the permissions aspect isn't
guaranteed to be supported on some BSD environments !
The name is however just a proxy for the socket itself. YouNo, but it is looked up the same way any other inode is (the
don't even get a device node in the usual sense or the same inode
in the file system space.
difference between FIFOs and sockets is that sockets have separate
connections, which is also why open() on sockets would be nice.)
However, there is a fundamental difference between AF_UNIX sockets
and open(), and that is how the pathname is delivered. It thus
would make more sense to provide the openat()-like information in
struct sockaddr_un, but that may be very hard to do in a sensible
way. In that sense it perhaps would be cleaner to be able to do
an open[at]() on the socket node with O_PATH (perhaps there should
be an O_SOCKET option, even?) and pass the resulting file
descriptor to bind() or connect().
will help us in checkpoint-restore, making handling of
overmounted/unlinked sockets much cleaner.
There should be some way how to connect/bind already existent unix
socket (from kernel, at least), because socket can be created in user
space. And this way (sock operation or whatever) have to provide an
ability to lookup UNIX socket starting from specified root to support
containers.
am I missing?
Kernel preform connect to rpcbind socket (i.e. user-space binds it),
doesn't it?
I'm confused, possibly because there are three "sockets" here: the
client-side socket that's connected, the server-side socket that's bound,
and the common object that exists in the filesystem namespace.
Userland creates the server-side socket and binds to it. All of that is
done in the context of the rpcbind process, so is created in rpcbind's
namespace. That should be OK, right?
The client side socket is created and connected in xs_local_setup_socket().
Making sure they both end up with the same thing is a matter of making sure
they lookup the same path in the same namespace. The difficult part of that
is the in-kernel client-side socket connect, where we don't have the right
process context any more.