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@xxxxxxxxxx> > --- > src/qemu/qemu.conf | 3 ++- > src/qemu/qemu_driver.c | 2 +- > 2 files changed, 3 insertions(+), 2 deletions(-) >
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list