Hi Bob, I think this email highlights a general issue around need a general library of common code for agents, since many of them will benefit from things like root-wrap, common logging code, etc. This is something I'd like to push for in Folsom (particularly in the scope of openstack-common), so you taking a lead on it is great.
My only concerns here are really around trying to adding the rootwrap capability right before we release our RC (target is tomorrow, wednesday). Would this change add dependencies to the agents, changing how distros need to package the agents, and affect the ability of someone to run the agents as a stand-alone file. If so, my feeling is that this is too disruptive for Essex. You mention that rootwrap would only be used if it is explicitly enabled, so if you could do that in a way that avoids the above disruptions, I think we could consider it, as I definitely see the value. Yet another case where openstack-common would really help :) Dan On Tue, Mar 13, 2012 at 10:01 AM, Sumit Naiksatam (snaiksat) < snaik...@cisco.com> wrote: > Hi Bob, Thanks for taking this up. Responses inline. > > ~Sumit. > > > -----Original Message----- > > From: Robert Kukura [mailto:rkuk...@redhat.com] > > Sent: Tuesday, March 13, 2012 9:40 AM > > To: Sumit Naiksatam (snaiksat); Dan Wendlandt; Brad Hall; > > netstack@lists.launchpad.net > > Cc: Christopher Wright > > Subject: bug 948467 - agent root_helper > > > > I intend to submit a patch today for RC1 so that the linuxbridge and > > openvswitch agents will no longer need to run as root. Instead, they > > will read a root_helper config variable and prepend that to the > > commands > > they execute, as nova does when it executes commands for which > > run_as_root is specified to nova.utils.execute(). Don't worry, I'm not > > pulling in nova.utils, just making minimal modifications to the > > single-file agent implementations. > > > > I'd like to get buy-in from the plugin agent owners and any other > > interested parties before submitting this, and get consensus on a > > couple > > of choices: > > > > 1) The default value for the root_helper could be "sudo" (as it is in > > nova), or could be empty. If the agent is already running as root, > then > > using sudo shouldn't hurt anything except for adding a tiny bit of > > overhead, so I'm inclined to put sudo in the .ini files for both > > plugins > > as the value for root_helper. In test situations where the user is not > > root but has unconstrained sudo privileges, it should no longer be > > necessary to run the agents as root. Any objection to defaulting to > > sudo? > > > > <Sumit> In the LinuxBridge plugin README we do recommend running the > agent as sudo, so your suggestion is consistent. </Sumit> > > > 2) Running the agents with unconstrained sudo privileges is not much > > more secure than running them as root. One option is for > > packages/deployments to run the agents as users who only have the > > needed > > sudo privileges (we could ship a specific sudoers file for each > agent). > > But a more secure option is to use the rootwrap functionality from > > nova, > > since it filters on the entire command line using regular expressions. > > Unfortunately, nova's rootwrap is not currently extensible, so we'd > > need > > to copy it into quantum, renaming the executable from nova-rootwrap to > > quantum-rootwrap. This seems like a good candidate for > openstack-common > > in folsom, but for now copying would be necessary, and also would > avoid > > depending on nova. So I am intending to copy the rootwrap > > implementation > > from nova into quantum and modify it as necessary to support these two > > agents. This will involve adding bin/quantum-rootwrap and adding a > > couple of modules in the quantum/rootwrap namespace, all with no > > non-standard imports. Note that, just as in nova, rootwrap will not be > > used at all unless packages/deployments explicitly enable it by > > changing > > root_helper from "sudo" to "quantum-rootwrap". Is everyone OK with > this > > plan? > > > > <Sumit> I do agree with the requirement for this, and your approach > seems a good one. However, I am a little jittery about this being > introduced late in the game. Would like to hear what the other folks > think. </Sumit> > > > 3) Would anyone object to adding a command line option to these two > > agents that causes them to log to a file as part of this patch? Or > > should that be handled separately? > > > > <Sumit> Definitely a very good suggestion. I would tend to think this is > a separate patch though. </Sumit> > > > Please let me know if you have any questions or issues and whether you > > are on board with this as soon as possible, as I'm proceeding with the > > work. > > > > > > Thanks, > > > > -Bob > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
