On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo <majop...@redhat.com>wrote:
> I'm not familiar with unix domain sockets at low level, but , I wonder
> if authentication could be achieved just with permissions (only users in
> group "neutron" or group "rootwrap" accessing this service.
>
It can be enforced, but it is not needed at all (see below).
> I find it an interesting alternative, to the other proposed solutions, but
> there are some challenges associated with this solution, which could make
> it more complicated:
>
> 1) Access control, file system permission based or token based,
>
If we pass the token to the calling process through a pipe bound to stdout,
it won't be intercepted so token-based authentication for further requests
is secure enough.
2) stdout/stderr/return encapsulation/forwarding to the caller,
> if we have a simple/fast RPC mechanism we can use, it's a matter
> of serializing a dictionary.
>
RPC implementation in multiprocessing module uses either xmlrpclib or
pickle-based RPC. It should be enough to pass output of a command.
If we ever hit performance problem with passing long strings we can even
pass opened pipe's descriptors over UNIX socket to let caller interact with
spawned process directly.
> 3) client side implementation for 1 + 2.
>
Most of the code should be placed in oslo.rootwrap. Services using it
should replaces calls to root_helper with appropriate client calls like
this:
if run_as_root:
if CONF.use_rootwrap_daemon:
oslo.rootwrap.client.call(cmd)
All logic around spawning rootwrap daemon and interacting with it should be
hidden so that changes to services will be minimum.
4) It would need to accept new domain socket connections in green threads
> to avoid spawning a new process to handle a new connection.
>
We can do connection pooling if we ever run into performance problems with
connecting new socket for every rootwrap call (which is unlikely).
On the daemon side I would avoid using fancy libraries (eventlet) because
of both new fat requirement for oslo.rootwrap (it depends on six only
currently) and running more possibly buggy and unsafe code with elevated
privileges.
Simple threaded daemon should be enough given it will handle needs of only
one service process.
> The advantages:
> * we wouldn't need to break the only-python-rule.
> * we don't need to rewrite/translate rootwrap.
>
> The disadvantages:
> * it needs changes on the client side (neutron + other projects),
>
As I said, changes should be minimal.
--
Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
