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. 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
