[neutron][nova][large scale SIG] Rootwrap daemon and privsep

Thierry Carrez thierry at openstack.org
Mon Dec 2 11:19:06 UTC 2019

Arnaud Morin wrote:
> [...]
> Still, one point is still confused in my mind.
> Now that we are supposed to use privsep in most cases, services (nova,
> neutron and others) are supposed to start some sort of privsep daemon
> (something called privsep-helper if I believe what I see running on my
> infra).
> With what you said, I suspect that this privsep-helper is bootstrapped
> through a rootwrap execution.

Yes. It obviously depends on packaging and how they start services, but 
by default this is how privsep-helper is started.

> First question is: is the daemon mode of rootwrap still needed?
> Maybe not if the whole nova code is using the privsep mechanism now?
> Maybe it is if some part of the code has not yet moved on privsep?

I'll defer to nova experts, but yes, it's a trade-off that depends on 
how much has already been migrated, and how often the remaining rootwrap 
commands are called. Looking at nova compute node it only has a couple 
of rootwrap filters left[1], but maybe the performance loss of dropping 
daemon mode there is acceptable.


> Moreover, if I take nova for exemple, I can see two privsep daemon
> running on my compute node:
> - one with context nova.privsep.sys_admin_pctxt
> - second with context vif_plug_linux_bridge.privsep.vif_plug
> Do you know why is it like that?

Privsep is finer-grained than rootwrap. Rather than just being root or 
non-root, you can require specific capabilities. See [2] for an example 
of such context definition. Privsep-helper starts as root and drops to 
the required capabilities to run with the minimum-needed privileges. 
That requires separate executables, one for each context. Specific 
libraries (like os_brick) or plugins can also come with their own 
privsep context.


Reading the initial spec[3] can give you extra context on how the change 
was driven. The current implementation has not strayed far away from 
that initial concept:


Thierry Carrez (ttx)

More information about the openstack-discuss mailing list