[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