[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]