On 5 February 2015 at 03:33, Monty Taylor <mord...@inaugust.com> wrote:
> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
....> to manage VMs on a laptop - you're going to use virtualbox or
> virt-manager. You're going to use nova-compute to manage compute hosts
> in a cloud - and in almost all circumstances the only thing that's going
> to be running on your compute hosts is going to be nova-compute.

Actually we know from user / operator stories at summits that many
groups run *much more* than nova-compute on their compute hosts.
Specifically the all-in-one scale-as-a-unit architecture is quite
popular. That has all the components of
cinder/swift/keystone/nova/neutron all running on all machines, and
the cluster is scaled by adding just another identical machine.

I suspect its actually really quite common outside of a) paranoid (but
not necessarily wrong :)) and b) ultra-scale environments.
...

I'm with Daniel -
>> (4) I think that ultimately we need to ditch rootwrap and provide a proper
>> privilege separated, formal RPC mechanism for each project.
>>
>> eg instead of having a rootwrap command, or rootwrap server attempting
>> to validate safety of
>>
>>     qemu-img create -f qcow2 /var/lib/nova/instances/instance00001/disk.qcow2
>>
>> we should have a  nova-compute-worker daemon running as root, that accepts
>> an RPC command from nova-compute running unprivileged. eg
>>
>>     CreateImage("instane0001", "qcow2", "disk.qcow")
>>
>> This immediately makes it trivial to validate that we're not trying to
>> trick qemu-img into overwriting some key system file.
>>
>> This is certainly alot more work than trying to patchup rootwrap, but
>> it would provide a level of security that rootwrap can never achieve IMHO.

I think a local root daemon is a solid idea, there's lots and lots of
prior art on this, from the bazillion dbus daemons we haveadays to the
Android isolation between apps.

So count me in too on design and speccing for this. I realise that for
some cases rootwrap was absolutely a performance and stability issue,
but daemon mode should address that - so I think this is a longer term
project, giving us a significant step up in security.

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__________________________________________________________________________
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

Reply via email to