[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?
Miguel Angel Ajo
majopela at redhat.com
Thu Mar 13 08:18:15 UTC 2014
Yuri, could you elaborate your idea in detail? , I'm lost at some
points with your unix domain / token authentication.
Where does the token come from?,
Who starts rootwrap the first time?
If you could write a full interaction sequence, on the etherpad, from
rootwrap daemon start ,to a simple call to system happening, I think
that'd help my understanding.
Best regards,
Miguel Ángel.
On 03/13/2014 07:42 AM, Yuriy Taraday wrote:
> On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo <majopela at redhat.com
> <mailto:majopela at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list