<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Personally I'm of the opinion that from an architectural POV, use of<br>
either rootwrap or sudo is a bad solution, so arguing about which is<br>
better is really missing the bigger picture. In Linux, there has been<br>
a move away from use of sudo or similar approaches, towards the idea<br>
of having privileged separated services. So if you wanted todo stuff<br>
related to storage, you'd have some small daemon running privilegd,<br>
which exposed APIs over DBus, which the non-privileged thing would<br>
call to make storage changes. Operations exposed by the service would<br>
have access control configured via something like PolicyKit, and/or<br>
SELinux/AppArmour.<br></blockquote><div><br></div><div>The more I think about this problem the more I'm convinced that rootwrap</div><div>simply exists to work around a fundamental design flaw in most (all?) of</div>
<div>the components: a single, threaded, process with poor job/workflow </div><div>mnemonics.</div><div><br></div><div>If the architecture was such that every operation was a task which could</div><div>be carried out by any process (even a process running on a different host)</div>
<div>and each process publishes job types that it can do, then you could do</div><div>proper isolation for just those processes that need to do privileged tasks.</div><div><br></div><div><a href="https://wiki.openstack.org/wiki/TaskFlow">https://wiki.openstack.org/wiki/TaskFlow</a> looks to be headed in the right<br>
</div><div>direction, but I worry it's got a very long road ahead.</div></div></div></div>