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 <majop...@redhat.com
<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
