On 31/03/2021 15:49, Ben Nemec wrote:
On 3/31/21 1:53 AM, Slawek Kaplonski wrote:
Hi,
On Tue, Mar 30, 2021 at 05:33:40PM +0200, Rodolfo Alonso Hernandez wrote:
Hello Neutrinos:
During the last cycles we have been migrating the Neutron code from oslo.rootwrap to oslo.privsep. Those efforts are aimed at reaching the goal defined in [1] and are tracked in [2].
At this point, starting Xena developing cycle, we can state that we have migrated all short lived commands from oslo.rootwrap to oslo.privsep or to a native implementation (that could also use oslo.privsep to elevate the permissions if needed).
Thanks a lot Rodolfo for working on that. Great job!
The problem are the daemons or services (long lived processes) that Neutron spawns using "ProcessManager"; this is why "ProcessManager.enable" is the only code calling "utils.execute" without "privsep_exec" parameter. Those process cannot be executed using oslo.privsep because the privsep root daemon has a limited number of executing threads.
The remaining processes are [3].
Although we didn't reach the Completion Criteria defined in [1], that is remove the oslo.rootwrap dependency, I think we don't have an alternative to run those services and we should keep rootwrap for them. If there are no objections, once [3] is merged we can consider that Neutron (not other Stadium projects) finished the efforts on [1].
Sounds good for me.
Please, any feedback is always welcome.
Maybe some oslo.privsep experts can take a look into that and help to solve that problem somehow. If not, then IMO we can live with it like it is now.
One possibility is to start a separate privsep daemon for the long-running services. I believe privsep was designed with that in mind so you could have privileged calls running in a daemon with just the necessary permissions for that call, not the permissions for every privileged call in the service. yes you are meen to have a deam process per privesep context and multiple context per service so that you only have the permissions you need. so neutron should have mutiple privsep context as should nova and use
im not sure i understand why this is a problem for you. you can define a context that is only used for those long running proces ot have them execute in sperate deamon with its own threads. the correct one for the calls it uses. the other anti patter to avoid is centralising all privsep cunciton in a set of common modules that are called into form differnt moduels. nova and neutorn are unfrotunetly both guilty of that too but eventully i would hope that that will be fixed.
That said, I'm not sure how much, if at all, it has been used.
Regards.
[1]https://review.opendev.org/c/openstack/governance/+/718177 [2]https://storyboard.openstack.org/#!/story/2007686 [3] https://review.opendev.org/c/openstack/neutron/+/778444/2/etc/neutron/rootwr...