[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.

[1] 
https://opendev.org/openstack/nova/src/branch/master/etc/nova/rootwrap.d/compute.filters

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

[2] 
https://opendev.org/openstack/nova/src/branch/master/nova/privsep/__init__.py

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:

[3] 
https://specs.openstack.org/openstack/oslo-specs/specs/liberty/privsep.html

-- 
Thierry Carrez (ttx)



More information about the openstack-discuss mailing list