Bug 1267154 - libvirt tries to change ownership of ISOs even though dynamic_ownership is set to 0
libvirt tries to change ownership of ISOs even though dynamic_ownership is se...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.2
All All
unspecified Severity high
: rc
: ---
Assigned To: Michal Privoznik
Virtualization Bugs
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-29 03:36 EDT by Jiri Denemark
Modified: 2015-11-19 01:55 EST (History)
15 users (show)

See Also:
Fixed In Version: libvirt-1.2.17-12.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1266628
Environment:
Last Closed: 2015-11-19 01:55:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Denemark 2015-09-29 03:36:36 EDT
+++ This bug was initially created as a clone of Bug #1266628 +++

[root@adam libvirt]# grep dynamic /etc/libvirt/qemu.conf
# Whether libvirt should dynamically change file ownership
dynamic_ownership = 0

yet, with libvirt 1.2.17-10, when I start a VM, it tries to change ownership of the ISO file attached to it (and fails, as it's on a network share). This prevents me running any VMs, in my setup.

Downgraded to 1.2.17-9, it works fine.

I kinda suspect this change:

https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=f4c60dfbf2ec606a5fc148b4c6ff1cd17ffd79ec

which adds a virSecurityDACSetOwnership call which is not protected by a block like this:

    if (!priv->dynamicOwnership)
        return 0;

which several of the others are. But not *all* of them are, and I'm not 100% sure exactly what that virSecurityDACDomainSetDirLabel() is for or what it operates on, so IMBW.

--- Additional comment from Cole Robinson on 2015-09-28 23:55:07 UTC ---

Thanks for the report... you were in the right ballpark but the breakage is a bit more subtle. Patch posted upstream:

https://www.redhat.com/archives/libvir-list/2015-September/msg01000.html


This bug is caused by patches for bug 1124841.
Comment 3 zhenfeng wang 2015-10-12 01:38:26 EDT
Reproduce this bug with libvirt-17.2-10

1.Set dynamic_ownership=0 in qemu.conf
#cat /etc/libvirt/qemu.conf
dynamic_ownership=0
user=qemu
group=qemu

#systemctl restart libvirtd

2.Prepare a guest with a cdrom and iso file inserted
#virsh dumpxml vm1
--
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/virtio-win-1.7.4.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

# ll /var/lib/libvirt/images/virtio-win-1.7.4.iso -Z
-rw-r--r--. root root system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/virtio-win-1.7.4.iso

3.Start the guest, guest could start successfully and libvirt have change the
ownership of isos and vmdisk even though dynamic_ownership is set to 0

# virsh start vm1
Domain vm1 started

# ps -efZ|grep vm1
system_u:system_r:svirt_t:s0:c122,c695 qemu 11614  1 88 13:23 ?        00:00:14 /usr/libexec/qemu-kvm -name vm1

# ll /var/lib/libvirt/images/vm924.qcow2 -Z
-rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c122,c695 /var/lib/libvirt/images/vm924.qcow2
# ll /var/lib/libvirt/images/virtio-win-1.7.4.iso -Z
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/virtio-win-1.7.4.iso


Verify this bug with libvirt-1.2.17-13.el7

SCENARIO 1
1.Rexcute step 1~2 in reproduce steps
2.start guest, guest will fail to start since qemu process didn't have
permission to use the disk 
# virsh start vm1
error: Failed to start domain vm1
error: internal error: process exited while connecting to monitor: 2015-10-10T07:11:56.035219Z qemu-kvm: -drive file=/var/lib/libvirt/images/vm924.1444384712,if=none,id=drive-virtio-disk0,format=qcow2: Could not open '/var/lib/libvirt/images/vm924.1444384712': Permission denied

3.chown the guest's disk to qemu:qemu, then start guest, guest could start successfully
# chown qemu:qemu vm924.qcow2
-rw-r--r--. 1 qemu qemu  9329508352 Oct 10 15:16 vm924.qcow2

# virsh start vm1
Domain vm1 started

# ll -Z /var/lib/libvirt/images/virtio-win-1.7.4.iso 
-rw-r--r--. root root system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/virtio-win-1.7.4.iso

# ll -Z /var/lib/libvirt/images/vm924.qcow2 
-rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c100,c368 /var/lib/libvirt/images/vm924.qcow2

SCENARIO 2
1.set dynamic_ownership=1
user=qemu
group=qemu

2.start a guest, guest could start successfully
# virsh start vm1
Domain vm1 star

# ll /var/lib/libvirt/images/virtio-win-1.7.4.iso  -Z
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/virtio-win-1.7.4.iso
[root@rhel73zhwang ~]# ll /var/lib/libvirt/images/vm924.qcow2 -Z
-rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c917,c940 /var/lib/libvirt/images/vm924.qcow2

3.Set per-vm dac in guest's xml, then start guest

#virsh dumpxml vm1
--
  </devices>
  <seclabel type='static' model='dac' relabel='yes'>
    <label>test1:test1</label>
  </seclabel>
</domain>
--
# virsh start vm1
Domain vm1 started

# ps -efZ|grep qemu
system_u:system_r:svirt_t:s0:c800,c867 test1 7844  1 87 11:04 ?        00:00:11 /usr/libexec/qemu-kvm -name vm1 

# ll /var/lib/libvirt/qemu/domain-vm1/ -Zd
drwxr-x---. test1 test1 system_u:object_r:svirt_image_t:s0:c800,c867 /var/lib/libvirt/qemu/domain-vm1/

# ll -Z /var/lib/libvirt/images/vm924.qcow2 
-rw-r--r--. test1 test1 system_u:object_r:svirt_image_t:s0:c800,c867 /var/lib/libvirt/images/vm924.qcow2

# ll -Z /var/lib/libvirt/images/virtio-win-1.7.4.iso 
-rw-r--r--. test1 test1 system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/virtio-win-1.7.4.iso

SCENARIO 3
Do regression test for bug 1124841, all verify steps in that 
bug could pass

According to upper steps, mark this bug verifed
Comment 5 errata-xmlrpc 2015-11-19 01:55:38 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html

Note You need to log in before you can comment on or make changes to this bug.