Open Stack

Thanks Thierry.
Is Neutron ready to switch oslo.rootwrap to oslo.privsep?
Oslo.privsep seem try to launch a daemon process and set caps for this daemon; but for XenAPI, there is no need to spawn the daemon. All of the commands to be executed are sent to the common dom0 XAPI daemon (which will invoke a dedicated plugin to execute the commands). So I'm confused how to apply the privileged.entrypoint function. Could you help to share more details? Thanks very much.

Jianghua

-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org] 
Sent: Wednesday, November 2, 2016 10:06 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Ihar Hrachyshka wrote:
> Tony Breeds <tony at bakeyournoodle.com> wrote:
> 
>> On Tue, Nov 01, 2016 at 12:45:43PM +0100, Ihar Hrachyshka wrote:
>>
>>> I suggested in the bug and the PoC review that neutron is not the 
>>> right project to solve the issue. Seems like oslo.rootwrap is a 
>>> better place to maintain privilege management code for OpenStack. 
>>> Ideally, a solution would be found in scope of the library that 
>>> would not require any changes per-project.
>>
>> With the change of direction from oslo.roowrap to oslo.provsep I 
>> doubt that there is scope to land this in oslo.rootwarp.
> 
> It may take a while for projects to switch to caps for privilege 
> separation.

oslo.privsep doesn't require projects to switch to caps (just that you rewrite the commands you call in Python) and can be done incrementally (while keeping rootwrap around for not-yet-migrated stuff)...

> It may be easier to unblock xen folks with a small enhancement in 
> oslo.rootwrap scope and handle transition to oslo.privsep on a 
> separate schedule. I would like to hear from oslo folks on where 
> alternative hypervisors fit in their rootwrap/privsep plans.

Like Tony said at this point new features are added to oslo.privsep rather than oslo.rootwrap. In this specific case the most forward-looking solution (and also best performance and security) would be to write a Neutron @privileged.entrypoint function to call into XenAPI and cache the connection.

https://review.openstack.org/#/c/155631 failed to land in Newton, would be great if someone could pick it up (maybe a smaller version to introduce privsep first, then migrate commands one by one).

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev