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

[Stanislav Kinsbursky <skinsbursky@parallels.com>]

On 22.05.2012 19:07, 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?
>

A kind of this, yes. Of course, if community will accept the idea.
Actually, bindat/connectat will be user space interfaces (they will be useful 
for out CRIU project and also will allow to remove UNIX socket path length 
limitation to 108 bytes).
On kernel level I'm going to add some way to pass "struct path" to connect/bind 
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?
>

Just a reminder: abstract (is it the right name?) UNIX sockets (with '\0' as a 
first character in name) are containerized already.
If UNIX socket is the only way. then maybe this "abstract" socket can be used?

> --b.


-- 
Best regards,
Stanislav Kinsbursky