Bug 1267154

Summary:	libvirt tries to change ownership of ISOs even though dynamic_ownership is set to 0
Product:	Red Hat Enterprise Linux 7	Reporter:	Jiri Denemark <jdenemar>
Component:	libvirt	Assignee:	Michal Privoznik <mprivozn>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	agedosier, berrange, clalancette, dyuan, extras-qa, itamar, jforbes, laine, libvirt-maint, lmiksik, mzhan, rbalakri, veillard, xuzhang, zhwang
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
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 06:55:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jiri Denemark 2015-09-29 07:36:36 UTC

+++ 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 1 Michal Privoznik 2015-09-29 13:58:47 UTC

Moving to POST:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2015-September/msg00676.html

Comment 3 zhenfeng wang 2015-10-12 05:38:26 UTC

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 06:55:38 UTC

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