Hide Forgot
libvirtd only changes the selinux labels of top two disk snapshots. When I used qemu-img to create 4 snapshot files like: base <- snap1 <- snap2 <- snap3 <- snap4 The guest can not start, selinux denied qemu-kvm access snap file. I checked the selinux labels of these snapshot files, only snap3 and snap4 are labeled. snap3 to "system_u:object_r:svirt_content_t:s0"(readonly) and snap4 to "system_u:object_r:virt_image_t:s0"(read/write). libvirtd should set the rest of backing files to "system_u:object_r:svirt_content_t:s0". Version: libvirt-1.1.1-13.el7.x86_64 qemu-kvm-rhev-1.5.3-19.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. create 4 snapshots using qemu-img # qemu-img create -f qcow2 -b kvm-rhel6.5-x86_64-qcow2.img kvm-rhel6.5-x86_64-qcow2-snap1.img Formatting 'kvm-rhel6.5-x86_64-qcow2-snap1.img', fmt=qcow2 size=4194304000 backing_file='kvm-rhel6.5-x86_64-qcow2.img' encryption=off cluster_size=65536 lazy_refcounts=off # qemu-img create -f qcow2 -b kvm-rhel6.5-x86_64-qcow2-snap1.img kvm-rhel6.5-x86_64-qcow2-snap2.img Formatting 'kvm-rhel6.5-x86_64-qcow2-snap2.img', fmt=qcow2 size=4194304000 backing_file='kvm-rhel6.5-x86_64-qcow2-snap1.img' encryption=off cluster_size=65536 lazy_refcounts=off # qemu-img create -f qcow2 -b kvm-rhel6.5-x86_64-qcow2-snap2.img kvm-rhel6.5-x86_64-qcow2-snap3.img Formatting 'kvm-rhel6.5-x86_64-qcow2-snap3.img', fmt=qcow2 size=4194304000 backing_file='kvm-rhel6.5-x86_64-qcow2-snap2.img' encryption=off cluster_size=65536 lazy_refcounts=off # qemu-img create -f qcow2 -b kvm-rhel6.5-x86_64-qcow2-snap3.img kvm-rhel6.5-x86_64-qcow2-snap4.img Formatting 'kvm-rhel6.5-x86_64-qcow2-snap4.img', fmt=qcow2 size=4194304000 backing_file='kvm-rhel6.5-x86_64-qcow2-snap3.img' encryption=off cluster_size=65536 lazy_refcounts=off 2. check label # ll -Z -rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 kvm-rhel6.5-x86_64-qcow2.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap1.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap2.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap3.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap4.img 3. configure guest to use kvm-rhel6.5-x86_64-qcow2-snap4.img as virtual disk, and start it # virsh edit kvm-rhel6.5-x86_64-qcow2-virtio Domain kvm-rhel6.5-x86_64-qcow2-virtio XML configuration edited. # virsh start kvm-rhel6.5-x86_64-qcow2-virtio error: Failed to start domain kvm-rhel6.5-x86_64-qcow2-virtio error: internal error: process exited while connecting to monitor: qemu-kvm: -drive file=/var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2-snap4.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2-snap4.img: Could not open file: Permission denied 4. we can see the labels of snap3 and snap4 are changed, but not for snap1 and snap2 # ll -Z -rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 kvm-rhel6.5-x86_64-qcow2.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap1.img -rw-r--r--. root root unconfined_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap2.img -rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 kvm-rhel6.5-x86_64-qcow2-snap3.img -rw-r--r--. root root system_u:object_r:virt_image_t:s0 kvm-rhel6.5-x86_64-qcow2-snap4.img Actual results： start fails Expected results: start success Additional info: The part of audit.log is: type=AVC msg=audit(1385522525.946:560): avc: denied { read } for pid=2609 comm="qemu-kvm" name="kvm-rhel6.5-x86_64-qcow2.snap2" dev="sda3" ino=526210 scontext=system_u:system_r:svirt_t:s0:c237,c674 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file type=SYSCALL msg=audit(1385522525.946:560): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9f7a3e40 a1=80800 a2=0 a3=0 items=0 ppid=1 pid=2609 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c237,c674 key=(null) type=AVC msg=audit(1385522525.946:561): avc: denied { read } for pid=2609 comm="qemu-kvm" name="kvm-rhel6.5-x86_64-qcow2.snap2" dev="sda3" ino=526210 scontext=system_u:system_r:svirt_t:s0:c237,c674 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file type=SYSCALL msg=audit(1385522525.946:561): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9f7a3e40 a1=80800 a2=0 a3=0 items=0 ppid=1 pid=2609 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c237,c674 key=(null) type=AVC msg=audit(1385522525.946:562): avc: denied { read } for pid=2609 comm="qemu-kvm" name="kvm-rhel6.5-x86_64-qcow2.snap2" dev="sda3" ino=526210 scontext=system_u:system_r:svirt_t:s0:c237,c674 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file
(In reply to Jincheng Miao from comment #0) > Steps to Reproduce: > 1. create 4 snapshots using qemu-img > # qemu-img create -f qcow2 -b kvm-rhel6.5-x86_64-qcow2.img > kvm-rhel6.5-x86_64-qcow2-snap1.img Oops. You forgot to request -o backing_fmt=qcow2. And I bet allow_disk_format_probing=0 in /etc/libvirt/qemu.conf (as setting it to 1 exposes you to a risk of a CVE of a guest overwriting a raw image with qcow2 headers in order to trick you into acting on those headers). The bug is not in libvirt, but in your setup. (Yes, libvirt should do a better job of showing you the chain it has parsed, and why it refuses to parse without probing if you forgot to set the metadata, but that's a lower-priority feature request). I'm closing this as not a bug, since the behavior is intentional.
see also bug 1044217, which is another bug on the same topic