[openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer
jianghua.wang at citrix.com
Wed Nov 2 15:31:49 UTC 2016
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.
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
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
More information about the OpenStack-dev