Open Stack

On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran
<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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140308/f2bcc02c/attachment.html>