[libvirt] RFC [3/3]: Lock manager usage scenarios

[Daniel P. Berrange]

On Thu, Sep 16, 2010 at 11:31:38AM -0400, David Teigland wrote:
> On Thu, Sep 16, 2010 at 01:50:46PM +0100, Daniel P. Berrange wrote:
> > The distinction is between what is possible, and what is recommended to
> > do. Even with the supervisor & QEMU having separate SELinux contexts,
> > it is still desirable to lock down the supervisor to only be able to
> > access the VM lease file & only its own QEMU pid. So while we could
> > write policy such that a supervisor can talk to a central lock daemon,
> > it is preferrable for the lock supervisor to be self contained.
> > 
> > The other point I make is that SElinux is the main security driver
> > today, but others will come along in the future. A container based
> > security driver will almost certainly completely isolate the spawned
> > processes with no option to talk to a central lock daemon. There would
> > be separate filesystem namespace, PID namespace, network namespace
> > per VM - in essence each process would see its own isolated OS with only
> > QEMU & the optional lock supervisor running in it.
> 
> Could containers make isolation exceptions for
> - shared storage devices?
> - shared /var/run/sync_manager/watchdog/ so that the system watchdog
>   could monitor all sync_manager instances?

Yes, resources (files) from the primary OS can be exposed in the
container on a case by case basis & potentially be visible inside
many containers. If we did a full virtual chroot setup, then the
container would only be able to see designated paths. It is also
possible to hide the containers chroot heirarchy from the host
completely. In any case, we can share paths between containers and
the host as needed.

A process inside the container would not be able to see any processes
outside the container. Processes outside can, however, see processes
inside the container, but its view of the PIDs will be different.
eg PID 1 inside the container may be PID 2345 outside.

The point I was trying to make, is that if the supervisor process
wants to connect back to a central lock daemon directly this might
run into trouble. If the supervisor process only needs to access
file resources on disk, it should be fine.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|