Open Stack

On Fri Feb 13 2015 at 4:05:33 PM Robert Collins <robertc at robertcollins.net>
wrote:

>
> On 13 Feb 2015 17:42, "Angus Lees" <gus at inodes.org> wrote:
> >
> > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
> wrote a proof-of-concept privsep daemon for neutron:
> https://review.openstack.org/#/c/155631
> > 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.
>
> Bravo. More conceptual than a code review my questions are. msgpack rather
> than protobuf ? Given your previous experience there I'm just curious.
>
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).

We could use json too if we wanted to avoid a new dependency, or presumably
numerous other choices.


>  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?
>
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.

In addition, the current simple fork/no-exec is also good for sharing most
of the pages in memory - making the overhead extremely minimal.

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.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150213/2be38319/attachment.html>