On Aug 1, 2013 2:06 AM, "Thierry Carrez" <[email protected]> wrote: > > Joe Gordon wrote: > > I tried > > swapping out rootwrap for sudo and that made the issue go away. So I > > think we should go back to supporting just using sudo instead of > > rootwrap, and make sure any future solutions support a sudo only option > > as well. But I am open to other ideas, I just think we need to > > implement something for Havana. > > How did you make the swap ? Patched utils.execute ? I guess we could > introduce some use_sudo_as_root_helper parameter (defaulting to False, > with security warnings) and preserve rootwrap_config as it is... >
Yes, or something like that. Hopefully it would be something in Oslo so other projects have this option. If they use rootwrap as well. Having rootwrap on by default makes nova-network scale very poorly by default. Which doesn't sound like a good default, but not sure if no rootwrap is a better default. So we may need a better story for deployers ... I haven't tried neutron perf yet but that may be better? But it won't be default until icehouse it looks like. > It will require a passwordless blanket sudo access for the nova user. Can't we go back to having a sudoers file white listing which binaries it can call, like before? > The trick is that this is equivalent to running Nova as the root user, > from a privilege escalation / security domain standpoint. And you can > already do that, and it will also "make the issue go away" (rootwrap is > bypassed if called from euid 0). > > It's cleaner to implement it as an option though, as it will not screw > up permissions everywhere in case you want to go back to using rootwrap > at some point in the future. > > Another important take-away from your comment is that we should preserve > the ability to run those commands under direct sudo... so if we want to > allow executing python snippets within rootwrap, we'd need to find a way > to do it with a call that is sudo-compatible, which might prove a bit > tricky. > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
