Thanks Doug. Please see my response inline starts with <jianghuaw>. Jianghua
-----Original Message----- From: Doug Hellmann [mailto:[email protected]] Sent: Wednesday, November 2, 2016 9:31 PM To: openstack-dev <[email protected]> Subject: Re: [openstack-dev] [neutron][oslo] proposal to resolve a rootwrap problem for XenServer Excerpts from Jianghua Wang's message of 2016-11-02 04:14:48 +0000: > Ihar and Tony, > Thanks for the input. > In order to run command in dom0, it uses XenAPI to create a session which > can be used to remotely call a plugin - netwrap which is located in dom0. The > netwrap plugin is executed as root. It will validate the command basing on > the allowed command list and execute it. > The source code for netwrap is in neutron project: > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/d > rivers/openvswitch/agent/xenapi/etc/xapi.d/plugins/netwrap > > So at least we can see there are two dependences: > 1. it depends on XenAPI which is XenServer specific. > 2. it depends on Neutron's plugin netwrap. > Is it acceptable to add such dependences in this common library of > oslo.rootwrap? Why would they need to be dependencies of oslo.rootwrap? They are dependencies of the driver, not the base library, right? <jianghuaw> With a second thought, I think we can pass the plugin name netwrap as a parameter to the rootwrap; so maybe not a dependence. But if we host the XenAPI session creation in oslo.rootwrap, I think we should import XenAPI in oslo.rootwrap. Then it is a dependence in the base library, isn't it? > And most of the code in oslo.rootwrap is to: > 1. spawn a daemon process and maintain the connection between the > client and daemon; 2. filter commands in the daemon process. > But both can't be re-used for this XenAPI/XenServer case as the daemon > process is already running in dom0; the command filtering is done in dom0's > netwrap plugin. In order to hold this in oslo.rootwrap, it requires some > refactoring work to make it looks reasonable. Is it worthy to do that? > Specially by considering it has determined to replace oslo.wrap with > oslo.provsep? > > Maybe it's a good option to cover this dom0 case in oslo.provsep at the > beginning. But it becomes more complicated. Maybe we can run a daemon process > in dom0 with the privileges set properly and listening on a dedicated tcp > port . But that's much different from the initial provsep design [1]. And > also it makes the mechanism very different from the current XenServer > OpenStack which is using XenAPI plugin. Anyway, I think we have long to go > with a good solution to cover it in provsep. What sort of refactoring do you have in mind for privsep? I could see something analogous to the preexec_fn argument to subprocess.Popen() to let the XenServer driver ensure that its privileged process is running in dom0. <jianghuaw>Sorry, I don't have a clear idea on refactorying in privsep now. It seems privsep attempts to create a daemon process and set caps for this daemon. But for XenServer/XenAPI, the daemon and caps in daemon seems useless. As it sends all commands to the a common XAPI daemon running in dom0. No additional daemon is needed. TBH I don't know how to apply caps at here. But to make it to resolve the current issue, what I'm thinking is to create a XenAPI session and keep it in the rootwrap's client; then each command will be passed to dom0 via this same session. Doug > > But this issue is urgent for XenAPI/XenServer OpenStack. Please the details > described in the bug[2]. So I still think the PoC is a better option, unless > both oslo and Neutron guys agree it's acceptable to refactor oslo.rootwrap > and allow the above dependences introduced to this library. > > [1]https://specs.openstack.org/openstack/oslo-specs/specs/liberty/priv > sep.html [2] https://bugs.launchpad.net/neutron/+bug/1585510 > > Regards, > Jianghua > > 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. > > Yours Tony. > > -----Original Message----- > From: Ihar Hrachyshka [mailto:[email protected]] > Sent: Tuesday, November 01, 2016 7:46 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] proposal to resolve a rootwrap > problem for XenServer > > Jianghua Wang <[email protected]> wrote: > > > Hi Neutron guys, > > > > I’m trying to explain a problem with the XenServer rootwrap and give > > a proposal to resolve it. I need some input on how to proceed with > > this > > proposal: e.g. if requires a spec? Any concerns need further > > discussion or clarification? > > > > Problem description: > > As we’ve known, some neutron services need run commands with root > > privileges and it’s achieved by running commands via the rootwrap. > > And in order to resolve performance issue, it has been improved to > > support daemon mode for the rootwrap [1]. Either way has the > > commands running on the same node/VM which has relative neutron services > > running on. > > > > But as a type-1 hypervisor, XenServer OpenStack has different behavior. > > Neutron’s compute agent neutron-openvswitch-agent need run commands > > in dom0, as the tenants’ interfaces are plugged in an integration > > OVS which locates in Dom0. Currently the script of > > https://github.com/openstack/neutron/blob/master/bin/neutron-rootwra > > p- xen-dom0is used as XenServer OpenStack’s rootwrap. This script > > will create a XenAPI session with dom0 and passes the commands to > > dom0 for the real execution. > > Each command execution will run this script once. So it has the > > similar performance issue as the non-daemon mode of rootwrap on > > other > > hypervisors: For each command, it has to parse the > > neutron-rootwrap-xen-dom0 script and the rootwrap configure file. > > Furthermore, this rootwrap script will create a XenAPI for each > > command execution and XenServer by default will log the XenAPI > > session creation events. It will cause frequent log file rotation > > and so other real useful log is lost. > > > > Proposal: > > The os.rootwrap support daemon mode for other hypervisors; but > > XenServer’s compute agent can’t use that as again it need run > > commands in Dom0. But we can refer to that design and implement the > > daemon mode for XenServer. After creating a XenAPI session, Dom0’s > > XAPI will accept the command running requests from the session and > > reply with the running result. So logically we’ve had a daemon in > > dom0. So we can support daemon mode rootwrap with the following design: > > 1. Develop a daemon client module for XenServer: The agent service > > will use this client module to create a XenAPI session, and keep > > this session during the service’s whole life. > > 2. once need run command on dom0, use the above client to runs > > commands in dom0. > > It should be able to result the issues mentioned above, as the > > client module need import only once for each agent service and only > > use a single session for all commands. The prototype code[3] works well. > > > > Any concern or comments for the above proposal? And how I can > > proceed with solution? We’ve filed a RFE bug[2] which is in > > wishlist&incomplete status. Per the neutron policy[4], it seems need > > neutron-drivers team to evaluate the RFE and determine if a spec is > > required. Could anyone help to evaluate this proposal and tell me > > how I should proceed? And I’m also open and happy for any comments. Thanks > > very much. > > > > [1] > > https://specs.openstack.org/openstack/oslo-specs/specs/juno/rootwrap > > -daemon-mode.html [2] > > https://bugs.launchpad.net/neutron/+bug/1585510 > > [3]prototype code: https://review.openstack.org/#/c/390931/ > > [4] > > http://docs.openstack.org/developer/neutron/policies/blueprints.html > > > > 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. > > I moved the bug to Opinion since I don’t believe it’s in scope for > neutron; I also added oslo.rootwrap to the list of affected projects > to collect feedback from oslo folks. Finally, I blocked the PoC patch > with -2 until we agree on how to scope the feature for neutron. > > I hope it helps, > Ihar > > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
