On Tue, 2012-05-22 at 11:31 -0400, J. Bruce Fields wrote: > On Tue, May 22, 2012 at 11:16:21AM -0400, Simo Sorce wrote: > > On Tue, 2012-05-22 at 11:07 -0400, J. Bruce Fields wrote: > > > On Tue, May 22, 2012 at 06:44:55PM +0400, Stanislav Kinsbursky wrote: > > > > Yep, we discussed it already. > > > > The problem is that connect call to unix sockets is done from rpciod > > > > workqueue because of selinux restrictions. > > > > IOW UNIX socket path will be traversed staring from rpciod kernel > > > > thread root. Currently this problem is existent for portmapper > > > > registration calls - for example LockD, started in container with > > > > nested root, will be registered in global rpcbind instead of local > > > > (container's) one. > > > > > > Thanks for the reminder! > > > > > > > One of solutions was to export set_fs_root(), but Al Viro doesn't like it. > > > > > > > > So currently I'm thinking about patching network layer - i.e. > > > > implementing an ability to pass desired path to unix sockets connect > > > > and bind calls. > > > > IOW, I'm talking about introducing of "bindat" and "connectat" system calls... > > > > > > So then we'd resolve the path in the right context and pass down a > > > (vfsmount, dentry) that rpciod could use in bindat/connectat calls? > > > > > > > >In particular: the current svcgssd communication method is using one of > > > > >the sunrpc caches. If we convert now to this method (which uses a unix > > > > >socket) would there be a loss in functionality, until the unix sockets > > > > >problems are fixed? > > > > > > > > > > > > > I'm afraid, that you are right... > > > > This new client will connect to root daemon - not containerized one... > > > > How soon this new unix-socket way will become common practice? > > > > Maybe I'd be able to patch unix sockets before distro's will use this new version. > > > > But I don't know, what would be best to do... > > > > > > Ugh. > > > > > > Simo, remind me of the reasons for using a unix socket? > > > > It's an RPC protocol, and we do not want the size limitations of other > > upcall mechanisms, we really want a stream. > > So what ruled out TCP over lo? Well it's a local-only protocol, it is not supposed to be available over a network, listning on a tcp port would require filtering at some level. Also, in user space, I depend on get_sockopts to get the peer creds and selinux context when user space client connect, I am not sure this info would be available over TCP, but in general it seem it would needlessly complicate things for the user space daemon, as you would need to use rpcbind to register the port and all that useless dance. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
