<div dir="ltr">Hi<div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2013 13:14, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">for managing VMs. Nova isn't using as much as it could do though. Nova<br></div>
isn't using any of libvirt's storage or network related APIs currently,<br>
which could obsolete some of its uses of rootwrap.</blockquote><div><br></div><div style>That certainly sounds like a useful thing that could happen regardless of what happens with sudo/rootwrap.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>  * DBus isn't super pleasing to work with as a developer or a sysadmin<br>
</div>No worse than OpenStack's own RPC system<br></blockquote><div><br></div><div style>Replacing a thing we don't really like, with another thing that isn't super awesome, may not be a good move :)</div><div style>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">As a host-local service only, I'm not sure high availability is really<br></div>
a relevant issue.</blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">but I still think it is better to have your root/non-root barrier defined<br></div>
in terms of APIs. It is much simpler to validate well defined parameters<br>
to API calls, than to parse & validate shell command lines. Shell commands<br>
have a nasty habit of changing over time, or being inconsistent across<br>
distros, or have ill defined error handling / reporting behaviour.<br>
<div class="HOEnZb"><div class="h5"></div></div></blockquote></div><div class="gmail_extra"><br></div>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.<br clear="all">
<div><br></div>-- <br><div dir="ltr">Cheers,<div><br></div><div>Chris</div></div>
</div></div>