This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours

Bug 517379

Summary: virt-manager should warn if guest images will are not readable by qemu
Product: [Community] Virtualization Tools Reporter: Adam Williamson <awilliam>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: berrange, crobinso, gthreepwood, hbrock, hundred17, lmr, markmc, michael.monreal+bugs, virt-maint, xen-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-07 17:23:55 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 498968    

Description Adam Williamson 2009-08-13 13:05:19 EDT
I cannot start a previously-existing VM configuration due to an error when trying to access any disk image I configure:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 567, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 652, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 293, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open disk image /home/adamw/Download/desktop-x86_64-20090811.17.iso

This happens for the 'hard disk' image in the same VM, if I leave it enabled, too. The file in question has these permissions:

[adamw@adam Download]$ ls desktop-x86_64-20090811.17.iso -l
-rw-rw-r--. 1 qemu qemu 740294656 2009-08-11 13:54 desktop-x86_64-20090811.17.iso

and is configured as the VM's CD/DVD drive. I have tried with SELinux disabled, makes no difference. This may be the same as 517308, but my traceback is different in the earlier stages. I'm using libvirt-0.7.0-4 now, but saw the same behaviour with the previous version too.
Comment 1 Daniel Berrange 2009-08-13 13:19:35 EDT
Can you check the permissions on /home/adamw  and /home/adanw/Download  to make sure both directories have at least  '--x' on them to allow 'qemu' user to access files

Also if you have SELinux enforcing mode, do you get an AVCs ?
Comment 2 Adam Williamson 2009-08-13 14:20:32 EDT
ah, you're right, that's probably the problem.

...

confirmed. OTOH, this strikes me as a significant usability problem. 'Download an ISO and create a VM to boot from it' is a pretty reasonable use case, and mostly people will download to their home directory. I suspect an awful lot of people would run into this problem if some kind of fix isn't implemented.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Daniel Berrange 2009-08-13 15:03:50 EDT
Yeah its kind of annoying that /home/$USER  defaults to mode 0700 instead of 0711.  Having libvirt automatically change individual files permissions is semi-reasonable, but I wouldn't want to make libvirt change home directory permissions too. I think it really requires some confirmation from the user before doing that kind of thing.


Perhaps virt-manager should explicitly watch for case where a user selects a location under $HOME, and then warn the user if their home directory, or an intermediate directory path has overly restricted permissions, offerring to fix.
Comment 4 Adam Williamson 2009-08-13 17:26:35 EDT
I guess I'm just not entirely convinced about the 'run qemu as qemu' thing. I ran virt-manager as adamw, I kinda am expecting it to work as if I'm running as me...if running as qemu introduces this kind of inconvenience I'm not sure it's a great idea. But you probably have a better overview than me :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Daniel Berrange 2009-08-14 04:41:24 EDT
It is a very important security feature. If QEMU runs as root, and there is a flaw in QEMU there is a very high chance it can be used to compromise the entire host. There have been many flaws in QEMU so this is well worth it and this would have limited the impact of several of them.
Comment 6 Adam Williamson 2009-08-14 12:05:21 EDT
couldn't qemu launch as the user who ran virt-manager in the first place?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Daniel Berrange 2009-08-14 13:28:26 EDT
It already does that if you connect to qemu:///session URIs. virt-manager uses qemu:///system URI by default though, since that's the only way you get useful network connectivity.
Comment 8 Adam Williamson 2009-08-14 13:39:16 EDT
Hmm. Okay. It just bugs me from a 'I'm a dumb user and know nothing about the technology' viewpoint; comparing it to the VMware or VirtualBox user experience, where I can run the app as a user and create a virtual machine in clicky-clicky fashion with the whole experience run as that user.

I know I'm probably setting an unrealistic target by comparing the user experience with no regard to the underlying technology, but that's the angle I'm coming at it from :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Hugh Brock 2009-09-17 13:45:04 EDT
"Perhaps virt-manager should explicitly watch for case where a user selects a
location under $HOME, and then warn the user if their home directory, or an
intermediate directory path has overly restricted permissions, offerring to
fix." strikes me as a pretty reasonable solution, regardless of which user qemu is running as.
Comment 10 Lucas Meneghel Rodrigues 2009-09-17 14:14:27 EDT
This is a pretty serious usability issue, since it's a common use case to have people creating virtual machines in disks contained in their own home directories, and even though the workaround is fairly simple (chmod 'o+x' /home/dir), there's no need to make the user to loose time trying to figure out what's wrong. The error one will see is along the lines:

Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open disk image /home/f12/Virt/images/opensolaris.img

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.6/site-packages/libvirt.py", line 1077, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: qemu: could not open disk image /home/f12/Virt/images/opensolaris.img

A user will think: Hey, this is on my home dir, how can I possibly not have access to this file? I created it myself with virt-manager?!?, so we shouldn't waste the user's time trying to figure out what's wrong (he probably has no idea that qemu is running under the qemu user).

It was pointed out that the proper solution for this issue would be to have good network support for qemu:///session, and therefore make qemu:///session the default for the desktop user. However, I don't think that's doable by F12 timeframe. 

So the solution pointed out by comment #9 would be the way to go for F12, IMHO, so I'd like to hear Cole Robinson opinions on that.
Comment 11 Mark McLoughlin 2009-09-21 09:35:13 EDT
(In reply to comment #10)
> This is a pretty serious usability issue

I agree. Moving to F12VirtBlocker
Comment 12 Mark McLoughlin 2009-09-21 09:37:21 EDT
See also bug #524033 and bug #523960
Comment 13 Mark McLoughlin 2009-09-21 12:04:33 EDT
*** Bug 524086 has been marked as a duplicate of this bug. ***
Comment 14 Cole Robinson 2009-09-21 14:39:28 EDT
(In reply to comment #10)
> This is a pretty serious usability issue, 

Yes, this certainly sucks. I should have tried to coordinate changes in the tools to match the libvirt change.

> The error one will see is along the lines:
> 
> Unable to complete install '<class 'libvirt.libvirtError'> internal error
> unable to start guest: qemu: could not open disk image
> /home/f12/Virt/images/opensolaris.img
> 

This is part of the problem: it would be helpful if qemu could at least print strerror output here (and for opening kernel/initrd). I filed this as bz 524695.

> 
> So the solution pointed out by comment #9 would be the way to go for F12, IMHO.

Agreed, I'm working on this now.
Comment 15 Cole Robinson 2009-09-24 12:10:07 EDT
This should be addressed in virt-manager-0.8.0-5.

When attaching any storage to a guest (via 'New VM' or 'Add Hardware') we will attempt to verify that the 'qemu' user has search access. If not, we warn the user and offer to fix, using ACLs. The user can opt out, and optionally 'Never ask about this path again" if we have any false positives.

Testing appreciated.
Comment 16 Joel 2009-09-28 09:59:06 EDT
Looks fixed as of virt-manager-0.8.0-5.fc12.noarch.
Comment 17 Cole Robinson 2009-09-29 15:08:57 EDT
Thanks for confirming.
Comment 18 Michael Monreal 2010-06-08 07:32:32 EDT
Regressed in F13 (virt-manager 0.8.3/0.8.4)?

Trying to boot from ISOs inside my home does *not* warn me of missing permissions and just gave an error on boot.

After 'setfacl -m u:qemu:x /home/`whoami`' the problem is gone.
Comment 19 Adam Williamson 2010-06-09 15:16:40 EDT
re-opening, then.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 20 Bug Zapper 2011-06-02 13:50:16 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Adam Williamson 2011-06-04 00:30:33 EDT
Anyone noticed the status of this lately? I haven't really.
Comment 22 Lucas Meneghel Rodrigues 2011-06-04 14:18:52 EDT
AFAIK, this is fixed as of Fedora 15 (Actually it was fixed long before that, maybe F13 or F14).
Comment 23 Cole Robinson 2011-06-07 12:06:32 EDT
Yeah I thought there were corner cases still lurking but I think they've all been shaken out. Closing
Comment 24 Adam Williamson 2011-08-09 15:07:41 EDT
hey, I just found another.

[adamw@vaioz Downloads]$ mount | grep /share/data
systemd-1 on /share/data type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
//192.168.1.13/Volume_1 on /share/data type cifs (rw,nosuid,relatime,sec=ntlm,unc=\\192.168.1.13\Volume_1,username=guest,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.13,unix,posixpaths,serverino,acl,rsize=8192,wsize=8192,actimeo=1)
[adamw@vaioz Downloads]$ ls -l /share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso 
-rwxrwxrwx. 1 adamw adamw 613416960 Aug  9 12:03 /share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso

(try to boot a virtual machine with that .iso file as the CD drive)

Error starting domain: unable to set user and group to '107:107' on '/share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso': Invalid argument

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/engine.py", line 959, in asyncfunc
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 1128, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unable to set user and group to '107:107' on '/share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso': Invalid argument

Well, yeah, it can't change the ownership of the file - it's on a CIFS share. But it has all the rights it could possibly need to the ISO. Shouldn't it be able to work *without* changing the file's ownership?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 25 Cole Robinson 2012-02-07 17:23:55 EST

*** This bug has been marked as a duplicate of bug 527736 ***