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? Dave -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list