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

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.