Open Stack

Going forward I think we should support two approaches:

1) some faster mostly python based (because we are a python project)
rootwrap solution, there are many good ideas proposed above.   Although
Robert Collins comments have yet to be addressed.
2) Also support just using sudo.

Assuming any sort of rootwrap solution we propose will incur a non-zero
overhead, I can imagine some users wanting to sacrifice some security for
performance.   For example if they run a private cloud where the tenants
are mostly trusted.



On Mon, Jul 29, 2013 at 1:00 PM, Fox, Kevin M <kevin.fox at pnnl.gov> wrote:

> How about a hybrid C/Python approach?
>
> The biggest performance issue seems to be python startup overhead, not the
> actual code execution time. Caching the python process could be used to
> solve the issue.
>
> You need to be able to execute the command quickly, so that says the
> command executed can't be python. But you could also make that program as
> minimal as possible, leaving everything else to python.
>
> So how about something like the following:
>
> In C, create a setuid program that opens a named pipe for write. If it
> opens ok, it writes out argv to the socket in one write. This will limit
> the command line to 512 bytes (Posix fifo atomic grantee) but should be
> enough I think.
> If the socket can't be opened for writing, a new python handler process is
> executed on the socket. There is a slight race here but should be
> handleable in the python process, perhaps with using semaphore locking. It
> then writes argv to the socket as above.
>
> The Python program starts up, loads all the libraries it needs, exits if
> it isn't "The one" and then proceeds to read on the socket. For each atomic
> read, it forks with the child. The fork should be cheep since python is
> already initialized. From there, the child can proceed exactly as it does
> today with all the regex stuff still in python.
>
> The C code is then very basic and easy to get right.
>
> Thanks,
> Kevin
> ________________________________________
> From: John Garbutt [john at johngarbutt.com]
> Sent: Monday, July 29, 2013 2:38 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Python overhead for rootwrap
>
> > Joe Gordon wrote:
> > time python -c "print 'test'"
>
> Is this a fair test, because I assume we don't need to compile
> rootwrap each time?
>
> Having said that, I believe you that there is overhead in starting python.
>
> >>> Mike Wilson wrote:
> >>>> In my opinion:
> >>>>
> >>>> 1. Stop using rootwrap completely and get strong argument checking
> >>>> support into sudo (regex).
>
> It seems like this is hard, and might pull us away from the finer
> grained control we would like.
>
> Rewriting rootwrap in C (option 4?) might work, but it would be a mine
> field of string handing errors in the filters.
>
> I tend to agree that (option 3) aggregating all of the calls to
> rootwrap may be impractical:
> > Sean Dague wrote:
> > The reason there are 20 different call outs is that they aren't all in
> the
> > same place. There are phases that happen here, and different kind of
> errors
> > needed. I'm skeptical that you could push it all into one place.
>
> However it seems like the quickest way to reduce _some_ of the impact.
>
> Maybe just have python command-lets, like the filters (python code
> that runs as root) that chain a set of shell requests, and the input
> is restricted by the filters in the usual way. I do worry that it
> encourages larger chunks of code running as root, but that is
> something we should be able to avoid.
>
> >>>> 2. Some sort of long lived rootwrap process, either forked by the
> >>>> service that want's to shell out or a general purpose rootwrapd type
> >>>> thing.
>
> Not sure we can have explored this sort of option fully.
>
> In general, it creates interesting permissions issues around the IPC,
> and obviously increases the amount of memory we consume.
>
> I am assuming that running rootwrap as another RPC consuming service,
> that runs as root on each host, would perform worse that starting
> python lots of times? Also, I am assuming that we get the messaging
> security tight enough that it would be secure enough.
>
> To improve performance, what about some kind of named pipe based "same
> host" RPC driver to reduce the overhead. The service.hostname queue
> could have a "local" equivalent, that could be used as a quick path,
> where it is enabled. I am assuming we could get such name pipes
> secured by appropriate groups. As an example, a rootwrap process (or
> something specific like "nova-compute-rootwrap") may only listen on a
> local route. But you could imagine things like nova-network and
> nova-compute using the local fast path also, while at the same time
> listening on the existing remote queues.
>
> Its not clear to me that named pipes would be any more performant that
> starting lots of python processes. Anyone tried that? My gut feeling
> is that we would need to test it first.
>
> John
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130729/8f882fb1/attachment.html>