[Pkg-libvirt-maintainers] Bug#843940: Bug#843940: libvirt-daemon: "Permission denied" errors in VMM/virt-manager when dynamic_ownership=0

[J Mo]

On 11/11/2016 10:48 AM, Guido Günther wrote:
> As far as I understand your report you're disabling the feature you
> want: having libvirt fixup permissions. If you disable it you have (or
> virt-manager) to do that.
>
> There might be a bug in virt-manager where it should take more care of
> adjusting permissions but it's hard to figure that out from your
> report. You don't give virt-manager-versions, file permissions, etc or
> what you did to get it to work.



The feature of libvirt to dynamically take ownership of files is 
confounding, bizarre, and obviously poorly thought out. I'm not alone in 
this opinion. A huge number of bugs and complaints have been filed about 
this issue, yet it remains:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/691590
https://www.redhat.com/archives/libvir-list/2011-September/msg00458.html

https://www.redhat.com/archives/libvirt-users/2010-January/msg00010.html
https://www.redhat.com/archives/libvirt-users/2010-January/msg00023.html

https://unix.stackexchange.com/questions/110357/prevent-libvirtd-from-modifying-file-attributes



All of these complaints were the reason the "dynamic_ownership" 
configuration option was apparently created in the first place.

The real source of our problems here is that libvirt changes the 
ownership of files outside of it's own directories, even when it doesn't 
need to do so. Libvirt has no justification to take user:group ownership 
of .iso files when it already has read access to them.

The workaround for this is to set dynamic_ownership=0. Unfortunately, 
that seems to be breaking the creation of new VMs, as my bug documents.



Just to be clear, my lack of information regarding details was an 
indication that defaults are being used: I have made no 
permission/ownership changes to anything in libvirt/qemu/et-cetera. I 
have made no configuration changes other than setting 
dynamic_ownership=0. This is a very new and default libvirt/virt-manager 
setup.

Reproducing this issue is as easy as my original report documents: Set 
dynamic_ownership=0 and create a new VM with a disk image.



When I have dynamic_ownership=0, and I create a new VM with libvirt and 
instruct it to create a new .qcow2 disk, it creates a new file in 
/var/lib/libvirt/images/

Unfortunately, the file remains owned by root:root, and libvirt fails to 
chown it:

[/var/lib/libvirt]
user at hostname-->sudo ls -alh --color images/
total 74G
drwx--x--x 2 root         root         4.0K Nov 11 17:18 .
drwxr-xr-x 6 root         root         4.0K Sep 23 19:10 ..
-rw------- 1 libvirt-qemu libvirt-qemu  41G Nov 10 18:03 
Debian_unstable.qcow2
-rw------- 1 root         root          21G Nov 11 17:18 generic.qcow2
-rw------- 1 libvirt-qemu libvirt-qemu  21G Nov 11 17:17 linuxmint-18.qcow2
-rw------- 1 libvirt-qemu libvirt-qemu  21G Oct  7 20:18 openSUSE.qcow2
-rw------- 1 libvirt-qemu libvirt-qemu 101G Oct  7 20:18 ubuntu14.04.qcow2



If I manually fix the ownership of the file, the VM then can start and 
works properly:

[/var/lib/libvirt]
user at hostname-->sudo chown libvirt-qemu:libvirt-qemu images/generic.qcow2



Thus, I'm put in the position where I either have to manually fix the 
ownership of all the .iso images that libvirt wrongly and unjustifiably 
takes ownership of, or I have to manually fix the ownership of the 
.qcow2 files. One way or the other, something is broken.