<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not familiar with unix domain sockets at low level, but , I wonder<br>
if authentication could be achieved just with permissions (only users in group "neutron" or group "rootwrap" accessing this service.<br></blockquote><div><br></div><div>It can be enforced, but it is not needed at all (see below).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
1) Access control, file system permission based or token based,<br></blockquote><div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) stdout/stderr/return encapsulation/forwarding to the caller,<br>
   if we have a simple/fast RPC mechanism we can use, it's a matter<br>
   of serializing a dictionary.<br></blockquote><div><br></div><div>RPC implementation in multiprocessing module uses either xmlrpclib or pickle-based RPC. It should be enough to pass output of a command.</div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) client side implementation for 1 + 2.<br></blockquote><div><br></div><div>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:</div>

<div><br></div><div>if run_as_root:</div><div>  if CONF.use_rootwrap_daemon:</div><div>    oslo.rootwrap.client.call(cmd)</div><div><br></div><div>All logic around spawning rootwrap daemon and interacting with it should be hidden so that changes to services will be minimum.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) It would need to accept new domain socket connections in green threads to avoid spawning a new process to handle a new connection.<br></blockquote><div><br></div><div>We can do connection pooling if we ever run into performance problems with connecting new socket for every rootwrap call (which is unlikely).</div>

<div>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.</div>

<div>Simple threaded daemon should be enough given it will handle needs of only one service process.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The advantages:<br>
   * we wouldn't need to break the only-python-rule.<br>
   * we don't need to rewrite/translate rootwrap.<br>
<br>
The disadvantages:<br>
  * it needs changes on the client side (neutron + other projects),<br></blockquote><div><br></div><div>As I said, changes should be minimal.</div><div><br></div></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>