[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