<div dir="ltr"><div class="gmail_quote">On Fri Feb 13 2015 at 4:05:33 PM Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On 13 Feb 2015 17:42, "Angus Lees" <<a href="mailto:gus@inodes.org" target="_blank">gus@inodes.org</a>> wrote:<br>
><br>
> So inspired by the "Rootwrap on root-intensive nodes" thread, I went and wrote a proof-of-concept privsep daemon for neutron: <a href="https://review.openstack.org/#/c/155631" target="_blank">https://review.openstack.org/#/c/155631</a><br>
> There's nothing neutron-specific in the core mechanism and it could easily be moved out into a common (oslo) library and reused across other projects.</p>
<p dir="ltr">Bravo. More conceptual than a code review my questions are. msgpack rather than protobuf ? Given your previous experience there I'm just curious.</p></blockquote><div>I have no educated preference between the two, and I didn't know of any high-performance precedent within openstack.  msgpack was just the first thing I came across that seemed well supported, fast, and only handled dumb types (no object auto-vivifying features that might backfire on us). </div><div><br></div><div>We could use json too if we wanted to avoid a new dependency, or presumably numerous other choices.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> </p>
<p dir="ltr">Are you concerned that commands might call into less trusted areas of code? Would it make sense to have the privileged commands be separate somehow to avoid this?</p></blockquote><div>Hrm, not particularly, although we should explore any implications.  If a standalone chunk of python imported other python libraries, then they may have a path that ends up with them able to be called - which I figure is similar to the current situation that also requires an explicit python import (or some other chain of object references).  If there's a bug that lets you escape the python level and run arbitrary C code, then it won't matter what's already loaded and we only have the linux capabilities/permissions mechanisms to save us.</div><div><br></div><div>In addition, the current simple fork/no-exec is also good for sharing most of the pages in memory - making the overhead extremely minimal.</div><div><br></div><div>Oh, if you mean "separate" just in a filesystem/code organisation sense, rather than a Linux process sense, then yes I do think they should be in a separate place for ease of auditing.  in my change above I have them all below a particular neutron.agent.privileged._commands prefix, and the communication assumes/restricts it to this.  We can of course pick another namespace prefix, but I agree that even with some different decorator-based method, I don't think we should just have privileged commands scattered anywhere throughout our regular codebase.</div><div><br></div><div> - Gus</div></div></div>