Open Stack

Hi

On 2 August 2013 13:14, Daniel P. Berrange <berrange at redhat.com> wrote:

> for managing VMs. Nova isn't using as much as it could do though. Nova
> isn't using any of libvirt's storage or network related APIs currently,
> which could obsolete some of its uses of rootwrap.


That certainly sounds like a useful thing that could happen regardless of
what happens with sudo/rootwrap.


> >  * DBus isn't super pleasing to work with as a developer or a sysadmin
> No worse than OpenStack's own RPC system
>

Replacing a thing we don't really like, with another thing that isn't super
awesome, may not be a good move :)


> As a host-local service only, I'm not sure high availability is really
> a relevant issue.


So, I mentioned that because exec()ing out to a shell script way fewer ways
it can go wrong. exec() doesn't go away and forget the thing you just asked
for, because something is being upgraded, or restarted, or crashed. I'm a
little rusty with DBus, but I don't think those sorts of things are well
catered for. Perhaps we don't care about that, but the change would be big
enough to at least figure out whether we care.


> but I still think it is better to have your root/non-root barrier defined
> in terms of APIs. It is much simpler to validate well defined parameters
> to API calls, than to parse & validate shell command lines. Shell commands
> have a nasty habit of changing over time, or being inconsistent across
> distros, or have ill defined error handling / reporting behaviour.
>

I do agree that privileged operations should be well defined and separated,
but I think in almost all cases you're going to find that the shell
commands are just moving to a different bit of code and will still be
fragile, just fragile inside a privileged daemon instead of fragile inside
a shell script. To pick a random example, nova's calls to iptables.
Something, somewhere is still going to be composing an iptables command out
of fragments and executing /sbin/iptables and hoping for a detailed answer.

Regardless of the mechanism used to implement this, I think that from the
perspective of someone hacking on the code that needs to make a privileged
call, and the code that implements that privileged call, the mechanism for
the call should be utterly transparent, as in, you are just calling a
method with some arguments in one place, and implementing that method and
returning something, in another place. That could be implemented on top of
sudo, root wrap, dbus, AMQP, SOAP, etc, etc.

-- 
Cheers,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/c263d064/attachment.html>