Open Stack

Bob Ball wrote:
>>> Oslo.privsep seem try to launch a daemon process and set caps for this
>> daemon; but for XenAPI, there is no need to spawn the daemon.
>>
>> I guess I'm lacking some context... If you don't need special rights, why use a
>> rootwrap-like thing at all ? Why go through a separate process to call into
>> XenAPI ? Why not call in directly from Neutron code ?
> 
> It does not need to go through a separate process at all, or need special rights - see the prototype code at https://review.openstack.org/#/c/390931/ which started this thread, which is directly calling from Neutron code.
> 
> I guess the argument is that we are trying to run "configure something" which in some cases is privileged in the same host as is running the Neutron code itself, hence the easiest way to do that is to use a rootwrap.  To me, the very use of a "rootwrap" or "privsep" implies that we're running the commands in the same host.

OK, I think I get it now: Neutron is using its rootwrap call interface
as an indirection layer to route configuration commands either to
execute as root locally (through classic rootwrap) or to execute on dom0
through a XenAPI connection (through rootwrap-xen-dom0). The latter
should really have been called xendom0wrap :)

> Arguably we should have a "per logical component" wrapper - in this case the network / OVS instance that's being managed - as each component could be in a different location.
> Mounting a loopback device (which Nova has needed to do in the past) clearly needs a rootwrap that runs in the same host as Nova, but when managing the OVS in XenServer's dom0 it needs a similar mechanism to what we are proposing for Neutron.
> 
> For reference, Nova has a XenAPI session similar to the above and will invoke plugins that exist in Dom0 directly, to make the required modifications.  This is similar in approach to the prototype code above.
> 
> The current XenAPI rootwrap for Neutron[1] is stupidly inefficient as it was based on the original rootwrap concept (which neutron replaced with the daemon mode to improve performance).  As this is a separate executable, called once for each command, it will create a new session with each call.  There are (as always) multiple ways to fix this:
> 
> 1) Get Neutron to call XenAPI directly rather than trying to use a daemon - the session management would move from neutron-rootwrap-xen-dom0 into xen_rootwrap_client.py (perhaps this could be better named) 

I personally like that option.

> 2) Get Neutron to call a local rootwrap daemon (as per the current implementation) which maintains a pool of connections and can efficiently call through to XenAPI

That is an option, yes. Basically rootwrap-xen-dom0 was created after
rootwrap, so it's doable to evolve it into a rootwrap-xen-dom0-daemon,
created after rootwrap-daemon. It is slightly more costly/complex than
running in-process, but would make it more reusable I guess.

> 3) Extend oslo.rootwrap (and I presume also privsep) to know that some commands can run in different places, and put the logic for connecting to those different places in there.

We don't really evolve rootwrap itself anymore, to focus on privsep. I
guess privsep could in the future grow beyond pure privilege separation
toward a more generic interface for executing code over security
boundaries... But that sounds pretty far away (time for neutron to adopt
privsep, time for privsep to grows desired features). So other options
are a more immediate fix to an immediate performance issue.

> We did have a prototype implementation of #2 but it was messy, and #1 seemed architecturally cleaner.

All 3 options are valid. I have a slight preference for #1 over #2 over
#3. Also code for #1 is already up.

Thanks for taking the time to explain it to me :)

-- 
Thierry Carrez (ttx)