moving mark and jay to BCC, as I added them mainly for the comments about openstack-common.
On Tue, Mar 13, 2012 at 10:52 AM, Robert Kukura <rkuk...@redhat.com> wrote: > > > > > > 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. > > The only modification to the agents is to read the root-helper config > option and prepend its value to the commands. The additional rootwrap > files should not be used and have no impact unless an agent is > configured to use quantum-rootwrap. > Ok, I thought you had mentioned additional modules that would have to be loaded, and since we don't do inline imports, I assumed that would be loaded regardless of config args. Or were you just talking about the filter files? At this point, perhaps an RFC patch would be best, so we can discuss concretely, assuming you can throw it together with fairly minimal effort. Dan > > See http://wiki.openstack.org/Packager/Rootwrap for packager > documentation. > > > > > Yet another case where openstack-common would really help :) > > Completely agree. > > -Bob > > > > > Dan > > > > > > > > On Tue, Mar 13, 2012 at 10:01 AM, Sumit Naiksatam (snaiksat) > > <snaik...@cisco.com <mailto:snaik...@cisco.com>> wrote: > > > > Hi Bob, Thanks for taking this up. Responses inline. > > > > ~Sumit. > > > > > -----Original Message----- > > > From: Robert Kukura [mailto:rkuk...@redhat.com > > <mailto:rkuk...@redhat.com>] > > > Sent: Tuesday, March 13, 2012 9:40 AM > > > To: Sumit Naiksatam (snaiksat); Dan Wendlandt; Brad Hall; > > > netstack@lists.launchpad.net <mailto: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 <http://www.nicira.com> > > twitter: danwendlandt > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
