Bug 924153

I have not tried to reproduce this yet, but it looks like a fairly reproducible setup, and therefore one that should still be solved for RHEL 7.

Could this be an artifact of using /tmp, where using a different directory doesn't have problems?

(In reply to Eric Blake from comment #3)
> Could this be an artifact of using /tmp, where using a different directory
> doesn't have problems?

Can you retest with a non /tmp directory and let us know the result?

(In reply to Dave Allan from comment #4)
> (In reply to Eric Blake from comment #3)
> > Could this be an artifact of using /tmp, where using a different directory
> > doesn't have problems?
> 
> Can you retest with a non /tmp directory and let us know the result?

Use the other dir, still get the same result

# virsh blockcopy virt-tests-vm1 vda /home/vm1.img --wait --verbose
error: internal error unable to execute QEMU command 'drive-mirror': /home/vm1.img: error while creating raw: Permission denied

# virsh blockcopy virt-tests-vm1 vda /var/lib/libvirt/images/virt-test-vim1.bk --wait --verbose
error: internal error unable to execute QEMU command 'drive-mirror': /var/lib/libvirt/images/virt-test-vim1.bk: error while creating raw: Permission denied

I reproduced the setup today using libvirt-0.10.2-21.el6.x86_64; there is definitely a SELinux labeling issue as I got an AVC; and retrying under permissive mode succeeds.  I'm stepping through gdb now, and should have a fix soon.

Root cause - we associate a single virSecurityDeviceLabelDefPtr to an entire disk image backing chain.  When initially assigning SELinux context to an image chain, if one of the images lives on NFS (and can't be labeled), we set 'norelabel = true' for the disk label struct.  Later, when trying to create a copy to a local disk, we short-circuit any attempts to label because of the existing file being unlabeled.  But the local copy MUST be labeled, or SELinux prevents qemu from using it.

I suspect a similar confusion might occur when trying to copy a local file to NFS; there, because norelabel=false, but the relabel attempt fails on the copy, it may confuse libvirt into not doing the copy; or maybe the copy will happen but then libvirt will fail to clean up the label on the source because it sees that there is no cleanup needed on the destination.  The ultimate solution is that we must track the label success or failure per element in the disk chain, rather than having a top-level view of the chain as a whole.

I'm trying to figure out how best to patch that...

Commit 904e05 (v0.9.9) introduced the use of norelabel=true in order to try and minimize the impact of shutdown delays on a system where NFS disappeared.  Bug 770985 describes what we did: if the disk couldn't be labeled, we alter the XML, so that on shutdown, we don't try to unlabel it (the unlabel is at best a no-op on NFS, but if the NFS server hangs, then we got stuck on the unlabel attempt).  Unfortunately, the way I solved that bug, I can't tell the difference between a disk where we added the annotation internally, and a disk where the user specified no labeling from the get-go.  And that labeling is currently per-disk, instead of per chain element

Upstream patch proposed:
https://www.redhat.com/archives/libvir-list/2013-August/msg00562.html

In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-August/msg01171.html

Verifying steps on this patch.

1. Check SElinux status
# getenforce
Enforcing
# getsebool virt_use_nfs
virt_use_nfs --> on

2. Mount the NFS storage on /var/lib/libvirt/images/nfs/.

3. Prepare the domain XML.
# cat > test.xml << EOF
<domain type='kvm'>
  <name>vm1</name>
  <memory unit='KiB'>131072</memory>
  <currentMemory unit='KiB'>131072</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/nfs/test.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c288,c802</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c288,c802</imagelabel>
  </seclabel>
</domain>
EOF

4. Create the domain.
# virsh create test.xml
Domain vm1 created from test.xml

5. Check Disk Security label and try to blockcopy image to local disk.
1) For with package libvirt-1.1.1-3.el7.x86_64

# virsh dumpxml vm1 | grep seclabel | head -n1                                   
        <seclabel model='selinux' relabel='no'/>

# virsh blockcopy vm1 vda /tmp/vm1.img --verbose --wait                                 
error: internal error: unable to execute QEMU command 'drive-mirror': /tmp/vm1.img: error while creating raw: Permission denied

2) For with package libvirt-1.1.1-4.el7.x86_64

# virsh dumpxml vm1 | grep seclabel | head -n1                                   
        <seclabel model='selinux' labelskip='yes'/>

# virsh blockcopy vm1 vda /tmp/vm1.img --verbose --wait                                 
Block Copy: [100 %]
Now in mirroring phase

For a image on NFS, property labelskip of seclabel is enabled and the image
can be copied to local disk.
So this patch is considered VERIFIED.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.