Bug 1181025 - emulator may not have search permissions, offers to correct it but then fails
Summary: emulator may not have search permissions, offers to correct it but then fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-12 08:48 UTC by Chris Murphy
Modified: 2015-06-23 09:14 UTC (History)
5 users (show)

Fixed In Version: virt-manager-1.1.0-9.git310f6527.fc21
Clone Of:
Environment:
Last Closed: 2015-06-23 09:14:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
XML example (2.53 KB, application/xml)
2015-02-27 15:47 UTC, gustavo.pedrosa
no flags Details

Description Chris Murphy 2015-01-12 08:48:58 UTC
Description of problem: virt-manager offers to fix multiple permissions problems, with No and Yes options. But the result is the same in either case, even if I choose Yes, it can't actually fix the problem but then continues anyway, only to fail completely at the very end of the wizard process.


Version-Release number of selected component (if applicable):
virt-manager-1.1.0-4.git310f6527.fc21.noarch

How reproducible:
Always

Steps to Reproduce:
1. Connect an external USB 3 drive. Gnome mounts this at /run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614
2. In virt-manager Edit > Connection Details > Storage, create a new pool of type Filesystem directory pointed to a directory on the above mounted drive.
3. There are two files in this directory:
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 dellrecoveryUSB.raw
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 windows8.qcow2

The raw file was created using dd from a bootable recovery USB stick.

4. Click on create a new virtual machine icon.
5. Local install media, click forward.
6. Use ISO image, Browse, dellrecoveryUSB.raw, uncheck Automatically detect since it's not being detected correctly and choose Windows / Windows 8.1, then click forward.
ERROR 1, followed by ERROR 2

Actual results:
ERROR 1: The emulator may not have search permission for the path '/run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614/dell/dellrecoveryUSB.raw' Do you want to correct this now? Yes / No. Upon choosing yes
ERROR 2: Errors were encountered changing permissions for the following directories: /run/media/chris:[Errno 1]Operation not permitted: '/run/media/chris'

Expected results:

First, I expect it to correct the problem it offers to correct. But if it can't actually do that, it shouldn't offer to correct it in the first place.


Additional info:

This is actually a fatal error in that the VM cannot be completed due to this error, but the UI allows me to proceed anyway, after dimissing ERROR 2. I'm at Choose Memory and CPU settings, so I fill that out and click forward. Next I'm to enable storage for this virtual machine by Select managed or other existing storage, Browse, and point to windows8.qcow2, click Forward, where I get ERROR 1 (except with the qcow2 filename), the same offer to correct the problem, and after saying yes, it does not correct the problem I get ERROR 2.

When I click Finish:

Unable to complete install: 'Cannot access storage file '/run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614/dell/windows8.qcow2' (as uid:107, gid:107): Permission denied'

Details:
Unable to complete install: 'Cannot access storage file '/run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614/dell/windows8.qcow2' (as uid:107, gid:107): Permission denied'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1854, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 411, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 475, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3440, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: Cannot access storage file '/run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614/dell/windows8.qcow2' (as uid:107, gid:107): Permission denied

Comment 1 gustavo.pedrosa 2015-02-27 15:47:17 UTC
Created attachment 996100 [details]
XML example

Comment 2 gustavo.pedrosa 2015-02-27 15:52:14 UTC
@Chris, when I try to run this XML example attached "virsh create langtest1.xml", it is returned the same error:
error: Cannot access storage file 'disk.img' (as uid:107, gid:107): Permission denied

Comment 3 Cole Robinson 2015-05-03 21:57:25 UTC
Thanks for the report. Firstly let me say that trying to create a system libvirtd qemu/kvm VM using files on a user mounted USB driver can be very difficult (and for some configurations impossible) without changing libvirt's security policies.

By default libvirtd wants to 1) give disk images a per-VM selinux label, to prevent other VMs from accessing their disk images, and 2) run qemu as the unprivileged qemu user/group

#1 doesn't seem to be at play here, but #2 is the hard part. The qemu user is unprivileged, and can only go where it has explicit permission. libvirt will try to chown disk images to qemu:qemu, but that's meaningless if some directory in the chain isn't searchable by the qemu user. This is what virt-manager is checking for, and it appears that /run/media/chris does not have world execute permissions. We attempt to fix it, both first with setfacl and then chmod +x, but that failed. Once that fails there isn't much else we can do.

> 
> Expected results:
> 
> First, I expect it to correct the problem it offers to correct. 
But if it
> can't actually do that, it shouldn't offer to correct it in the first place.
> 

When it comes to permission issues, it's very difficult to determine ahead of time if what we want to attempt is going to fail. Maybe our user doesn't have the appropriate permissions, or it's a readonly FS, or selinux will prevent us, or the FS doesn't have the proper support, and probably a dozen other obscure cases. If we got into the business of only offering to fix the problem when we _know_ it will succeed, we would end up with false positive cases where we don't attempt to fix things when it _would_ have worked.

So we would do it if we could, but it's a difficult problem.


> 
> Additional info:
> 
> This is actually a fatal error in that the VM cannot be completed due to
> this error, but the UI allows me to proceed anyway, after dimissing ERROR 2.
> I'm at Choose Memory and CPU settings, so I fill that out and click forward.
> Next I'm to enable storage for this virtual machine by Select managed or
> other existing storage, Browse, and point to windows8.qcow2, click Forward,
> where I get ERROR 1 (except with the qcow2 filename), the same offer to
> correct the problem, and after saying yes, it does not correct the problem I
> get ERROR 2.
> 
> When I click Finish:
> 
> Unable to complete install: 'Cannot access storage file
> '/run/media/chris/f968ce95-73b6-490b-89cf-ce57ef632614/dell/windows8.qcow2'
> (as uid:107, gid:107): Permission denied'

Right. Again this is a similar situation. We are pretty sure that VM install _will_ fail, but it's very difficult to be sure because there are many factors at play when considering disk permissions. Also maybe you use a different path via the customize wizard or something. So if we outright refuse to let you continue, we could have false postives.

However I've added an extra string to the UI after we report the failure: It is very likely the VM fill fail to start up. That's about the best I can think of at the moment

Comment 4 Cole Robinson 2015-05-03 21:57:38 UTC
Commit is:

commit cc67f8f194e1d7469f9a8d012754c39e986a74f0
Author: Cole Robinson <crobinso>
Date:   Sun May 3 17:33:26 2015 -0400

    addstorage: Clarify that VM will fail if cant set path search perms
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1181025

Comment 5 Chris Murphy 2015-05-06 01:11:25 UTC
Thing is, gnome-boxes will use the same (source install media) ISO on an external USB that virt-manager won't. That doesn't really make sense to me.

gnome-boxes-3.16.1-1.fc22.x86_64
virt-manager-1.1.0-7.git6dbe19bd8.fc22.noarch

Comment 6 Cole Robinson 2015-05-06 15:10:56 UTC
(In reply to Chris Murphy from comment #5)
> Thing is, gnome-boxes will use the same (source install media) ISO on an
> external USB that virt-manager won't. That doesn't really make sense to me.
> 
> gnome-boxes-3.16.1-1.fc22.x86_64
> virt-manager-1.1.0-7.git6dbe19bd8.fc22.noarch

boxes connects to a libvirtd instance running as your user (libvirt qemu:///session). VMs end up running as your user:group
libvirtd connects to libvirtd started by systemd (libvirt qemu:///system). VMs end up running as qemu:qemu

boxes doesn't use qemu:///session because it avoids these types of issues, but it has less functionality (historically inflexible networking, no PCI device assignment, a few other random things)

Comment 7 Cole Robinson 2015-05-06 15:16:35 UTC
> 
> boxes doesn't use qemu:///session because it avoids these types of issues,
> but it has less functionality (historically inflexible networking, no PCI
> device assignment, a few other random things)

that should say: boxes _uses_ qemu:///session because ...

Comment 8 Fedora Update System 2015-06-06 22:31:45 UTC
virt-manager-1.1.0-9.git310f6527.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/virt-manager-1.1.0-9.git310f6527.fc21

Comment 9 Fedora Update System 2015-06-09 15:03:35 UTC
Package virt-manager-1.1.0-9.git310f6527.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-1.1.0-9.git310f6527.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-9641/virt-manager-1.1.0-9.git310f6527.fc21
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2015-06-23 09:14:45 UTC
virt-manager-1.1.0-9.git310f6527.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


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