Open Stack

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. 
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 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 
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/rootwrap.d/rootwrap.filters 
>>>
>>
>