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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux