Bug 1027038

Summary:	libvirt-manager fails to open install ISO
Product:	[Fedora] Fedora	Reporter:	Jeremy Harris <jeharris>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	berrange, clalancette, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-06 09:08:21 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 Jeremy Harris 2013-11-06 00:11:46 UTC

Description of problem:

 Creating new VM under f20 host.


Version-Release number of selected component (if applicable):
 virt-manager 0.10.0
 libvirt.x86_64 0:1.1.3-2.fc20 


How reproducible:
 100%


Steps to Reproduce:
1. virt-manager new VM
2. "Finish" button
3.

Actual results:
 Error popup window:
Unable to complete install: 'internal error: process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
qemu-system-x86_64: -drive file=/home/jgh/Downloads/RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/jgh/Downloads/RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso: Permission denied

doublecheck ISO:
-rw-rw-r--. 1 qemu qemu 4560257024 Jul 22 14:58 RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso



Expected results:
  Install begins.


Additional info:
  Multiple ISOs tried, from RHEL5.1 to OpenIndiana.  Any attempted seems to get chowned qemu:qemu.
The kvm-pit issue is bz 978719.

Comment 1 Laine Stump 2013-11-06 09:08:21 UTC

The chown of the iso to qemu:qemu is normal; that is done because the qemu process is run as qemu:qemu (to prevent a compromised qemu process from doing anything nasty).

This problem was reported last week in Bug 1025355, and I reproduced it. The issue seems to be that one of the parent directories of the image file (usually /home/$user) is set to mode 710 (or possibly 700) so even changing the owner of the file itself to qemu:qemu doesn't help. virt-manager is supposed to ask if you want to fix this problem, and fix it.

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

Comment 2 Jeremy Harris 2013-11-06 18:01:13 UTC

I realise I'm shouting into the void here, but...  these were My Files.  Why do you, qemu, go and *steal* them?   Perfectly reasonable for you to say "I need this .iso world-readable, and the path searchable".  But changing the ownerships?  Hey - go the whole hog and move them somewhere else, or encrypt them or something...

If it isn't clear, I think you're violating the principle of least astonishment.