Hi Carl, thank you, good idea. I started reviewing it, but I will do it more carefully tomorrow morning.
----- Original Message ----- > All, > > 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. > > https://etherpad.openstack.org/p/neutron-agent-exec-performance > > Carl > > On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo <majop...@redhat.com> > wrote: > > 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.g...@theguardian.com <mailto:stephen.g...@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@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
