On Fri Feb 13 2015 at 4:05:33 PM Robert Collins <robe...@robertcollins.net> wrote:
> > On 13 Feb 2015 17:42, "Angus Lees" <g...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
