[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?
Miguel Angel Ajo Pelayo
mangelajo at redhat.com
Mon Mar 10 22:26:39 UTC 2014
Hi Carl, thank you, good idea.
I started reviewing it, but I will do it more carefully tomorrow morning.
----- Original Message -----
> I was writing down a summary of all of this and decided to just do it
> on an etherpad. Will you help me capture the big picture there? I'd
> like to come up with some actions this week to try to address at least
> part of the problem before Icehouse releases.
> On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo <majopela at redhat.com>
> > Hi Yuri & Stephen, thanks a lot for the clarification.
> > I'm not familiar with unix domain sockets at low level, but , I wonder
> > if authentication could be achieved just with permissions (only users in
> > group "neutron" or group "rootwrap" accessing this service.
> > I find it an interesting alternative, to the other proposed solutions, but
> > there are some challenges associated with this solution, which could make
> > it
> > more complicated:
> > 1) Access control, file system permission based or token based,
> > 2) stdout/stderr/return encapsulation/forwarding to the caller,
> > if we have a simple/fast RPC mechanism we can use, it's a matter
> > of serializing a dictionary.
> > 3) client side implementation for 1 + 2.
> > 4) It would need to accept new domain socket connections in green threads
> > to
> > avoid spawning a new process to handle a new connection.
> > The advantages:
> > * we wouldn't need to break the only-python-rule.
> > * we don't need to rewrite/translate rootwrap.
> > The disadvantages:
> > * it needs changes on the client side (neutron + other projects),
> > Cheers,
> > Miguel Ángel.
> > On 03/08/2014 07:09 AM, Yuriy Taraday wrote:
> >> On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran
> >> <stephen.gran at theguardian.com <mailto:stephen.gran at theguardian.com>>
> >> wrote:
> >> Hi,
> >> Given that Yuriy says explicitly 'unix socket', I dont think he
> >> means 'MQ' when he says 'RPC'. I think he just means a daemon
> >> listening on a unix socket for execution requests. This seems like
> >> a reasonably sensible idea to me.
> >> Yes, you're right.
> >> On 07/03/14 12:52, Miguel Angel Ajo wrote:
> >> I thought of this option, but didn't consider it, as It's somehow
> >> risky to expose an RPC end executing priviledged (even filtered)
> >> commands.
> >> subprocess module have some means to do RPC securely over UNIX sockets.
> >> I does this by passing some token along with messages. It should be
> >> secure because with UNIX sockets we don't need anything stronger since
> >> MITM attacks are not possible.
> >> If I'm not wrong, once you have credentials for messaging, you can
> >> send messages to any end, even filtered, I somehow see this as a
> >> higher
> >> risk option.
> >> As Stephen noted, I'm not talking about using MQ for RPC. Just some
> >> local UNIX socket with very simple RPC over it.
> >> And btw, if we add RPC in the middle, it's possible that all those
> >> system call delays increase, or don't decrease all it'll be
> >> desirable.
> >> Every call to rootwrap would require the following.
> >> Client side:
> >> - new client socket;
> >> - one message sent;
> >> - one message received.
> >> Server side:
> >> - accepting new connection;
> >> - one message received;
> >> - one fork-exec;
> >> - one message sent.
> >> This looks like way simpler than passing through sudo and rootwrap that
> >> requires three exec's and whole lot of configuration files opened and
> >> parsed.
> >> --
> >> Kind regards, Yuriy.
> >> _______________________________________________
> >> 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
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev