RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1124841 - unable to connect virtio-win images to qemu:///session VM: unable to set security context on iso/vfd image
Summary: unable to connect virtio-win images to qemu:///session VM: unable to set secu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-30 12:38 UTC by David Jaša
Modified: 2015-11-19 05:46 UTC (History)
5 users (show)

Fixed In Version: libvirt-1.2.17-10.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 05:46:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description David Jaša 2014-07-30 12:38:39 UTC 
Description of problem:
User can not start VMs running in qemu:///session per-user session because security context on virtio-win can not be changed

Version-Release number of selected component (if applicable):
libvirt-1.1.1-29.el7_0.1.x86_64
selinux-policy-3.12.1-153.el7_0.10.noarch

How reproducible:
always

Steps to Reproduce:
1. create a VM in user session. Note: to connect user session to virt-manager, add it to the connections:
$ dconf write /org/virt-manager/virt-manager/connections/uris "['qemu:///system', 'qemu:///session']"
2. attach an cdrom/floppy device, add some of the virtio images to it
3. start VM

Actual results:
vm can not start, error is thrown:
error: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/usr/share/virtio-win/virtio-win-1.7.0.iso': Operation not permitted

Expected results:
VM is started with virtio floppy/cdrom successfully attached

Additional info:
Comment 1 David Jaša 2014-07-30 12:41:53 UTC 
This may be an issue with selinux policy and/or virtio-win actually:

[root@cihla ~]# restorecon -FvvR /usr/share/virtio-win/
[root@cihla ~]# ls -lZ /usr/share/virtio-win/
drwxr-xr-x. root root system_u:object_r:usr_t:s0       drivers
drwxr-xr-x. root root system_u:object_r:usr_t:s0       guest-agent
-rw-r--r--. root root system_u:object_r:usr_t:s0       virtio-win-1.7.0_amd64.vfd
-rw-r--r--. root root system_u:object_r:usr_t:s0       virtio-win-1.7.0.iso
-rw-r--r--. root root system_u:object_r:usr_t:s0       virtio-win-1.7.0_x86.vfd
lrwxrwxrwx. root root system_u:object_r:usr_t:s0       virtio-win_amd64.vfd -> virtio-win-1.7.0_amd64.vfd
lrwxrwxrwx. root root system_u:object_r:usr_t:s0       virtio-win.iso -> virtio-win-1.7.0.iso
lrwxrwxrwx. root root system_u:object_r:usr_t:s0       virtio-win_x86.vfd -> virtio-win-1.7.0_x86.vfd
Comment 4 Michal Privoznik 2015-07-15 13:02:49 UTC 
Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2015-July/msg00576.html
Comment 5 Michal Privoznik 2015-09-10 12:47:37 UTC 
Another try:

https://www.redhat.com/archives/libvir-list/2015-September/msg00392.html
Comment 6 Michal Privoznik 2015-09-15 09:52:29 UTC 
Moving to POST:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2015-September/msg00254.html
Comment 8 zhenfeng wang 2015-09-24 09:02:42 UTC 
Hi Michal 
The following steps were my whole reproduce and verify steps, can you help
check whether i miss something or not, thanks

Reproduce
pkginfo
libvirt-1.2.17-9.el7.x86_64

steps
1.Keep selinux enabled in host
# getenforce
Enforcing

2.create a VM in user session. Note: to connect user session to virt-manager,
add it to the connections:
$ dconf write /org/virt-manager/virt-manager/connections/uris "['qemu:///system', 'qemu:///session']"

3.Edit guest's xml, add a cdrom and a iso file to the cdrom

#virsh dumpxml vm
--
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/usr/share/virtio-win/virtio-win-1.7.4.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

4.Start the guest, guest will fail to start with permission deny

$ virsh start vmn
error: Failed to start domain vmn
error: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/usr/share/virtio-win/virtio-win-1.7.4.iso': Operation not permitted


check the iso's permission
# ll -Z /usr/share/virtio-win/virtio-win-1.7.4.iso 
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/virtio-win/virtio-win-1.7.4.iso

====================================================================================================

Verify this bug with libvirt-1.2.17-10.el7.x86_64

1.Re-excute step 1~3 in reproduce steps
2.Start guest, guest could start successfully, check the iso's label, the label didn't changed
$ virsh start vmn
Domain vmn started

$ ps -efZ|grep vmn
unconfined_u:unconfined_r:svirt_t:s0:c284,c509 test1 16104 1 50 16:05 ? 00:00:08 /usr/libexec/qemu-kvm -name vmn 

# ll -Z /usr/share/virtio-win/virtio-win-1.7.4.iso
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/virtio-win/virtio-win-1.7.4.iso

3.Destroy the guest,then Delete the cdrom from guest's xml and then add a floopy to the guest
#virsh dumpxml vm
--
    <disk type='file' device='floppy'>
      <driver name='qemu' type='raw'/>
      <source file='/usr/share/virtio-win/virtio-win-1.7.4_x86.vfd'/>
      <target dev='fda' bus='fdc'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

4.Start the guest, the guest will fail to start

$ virsh start vmn
error: Failed to start domain vmn
error: internal error: process exited while connecting to monitor: 2015-09-24T08:09:21.641665Z qemu-kvm: -drive file=/usr/share/virtio-win/virtio-win-1.7.4_x86.vfd,if=none,id=drive-fdc0-0-0,format=raw: Could not open '/usr/share/virtio-win/virtio-win-1.7.4_x86.vfd': Permission denied


# ll -Z /usr/share/virtio-win/virtio-win-1.7.4_x86.vfd
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/virtio-win/virtio-win-1.7.4_x86.vfd

5.Could successfully attach a exsiting disk which created by root to the guest which created by non-root user with readonly mode,
also the disk's label won't change after hotplug

#qemu-img create /usr/share/virtio-win/test.img 100M
# ll -Z /usr/share/virtio-win/test.img 
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/virtio-win/test.img

$ virsh attach-disk vmn /usr/share/virtio-win/test.img vdb --mode readonly
Disk attached successfully

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/usr/share/virtio-win/test.img'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <readonly/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>


# ll -Z /usr/share/virtio-win/test.img 
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/virtio-win/test.img

6.Configure guest agent in the guest
$virsh dumpxml vmn
--
   <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>

7.Start the guest, guest could start successfully and generate the unix socket correctly
#virsh dumpxml vmn
--
      <source mode='bind' path='/home/test1/.config/libvirt/qemu/channel/target/domain-vmn/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>

$ ll -Z /home/test1/.config/libvirt/qemu/channel/target/domain-vmn/org.qemu.guest_agent.0
srwxrwxr-x. test1 test1 unconfined_u:object_r:svirt_image_t:s0:c681,c938 /home/test1/.config/libvirt/qemu/channel/target/domain-vmn/org.qemu.guest_agent.0

$ virsh domtime vmn --pretty
Time: 2015-09-24 08:32:24
Comment 9 Michal Privoznik 2015-09-24 11:49:14 UTC 
(In reply to zhenfeng wang from comment #8)
> Hi Michal 
> The following steps were my whole reproduce and verify steps, can you help
> check whether i miss something or not, thanks

You didn't. This can be moved to VERIFIED.

Michal
Comment 10 zhenfeng wang 2015-09-25 05:24:55 UTC 
Thanks, according to comment9, mark this bug verifed
Comment 12 errata-xmlrpc 2015-11-19 05:46:23 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
Note You need to log in before you can comment on or make changes to this bug.