[neutron][nova][large scale SIG] Rootwrap daemon and privsep
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
> 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, 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  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
Reading the initial spec 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