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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
