Re: [PATCH 3/4] SUNRPC: Add RPC based upcall mechanism for RPCGSS auth

[Simo Sorce <simo@redhat.com>]

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