On Fri, Jan 22, 2016 at 03:56:08PM +0000, Daniel P. Berrange wrote:
We have had virtlockd available for a long time now but
have always defaulted to the 'nop' lock driver which does
no locking. This gives users an unsafe deployment by
default unless they know to turn on lockd.
Does the default setup of virtlockd offer any safety?
After looking at:
https://bugzilla.redhat.com/show_bug.cgi?id=1191802
It seems that with dynamic_ownership enabled we first apply
the security labels, then check the disk locks by calling
virDomainLockProcessResume right before starting the CPUs
in virDomainLockProcessResume. After that fails, resetting
the uid:gid back to root:root cuts off the access to the disk
for the already running domain.
Is there a reason why the locks are checked so late?
I assume this only ever worked for the case of migration with
shared storage (and shared lockspace).
Jan
virtlockd will
auto-activate via systemd when guests launch, so setting
it on by default will only cause upgrade pain for people
on non-systemd distros.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/qemu/qemu.conf | 3 ++-
src/qemu/qemu_driver.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)