Bug 539369 - virt-manager fails to set security for path to iso image
virt-manager fails to set security for path to iso image
Status: CLOSED DUPLICATE of bug 530210
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-19 18:16 EST by Jonathan Underwood
Modified: 2009-11-20 14:35 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-20 14:27:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2009-11-19 18:16:09 EST
Description of problem:
When, as root, creating a new guest from an iso image which is *not* located in /var/lib/libvirt/images, after selecting the path to the iso file, I get a dialogue box saying:

"The emulator may not have search permissions for the path '/home/xxx/w32/WindowsXP/WindowsXP.iso'.

Do you want to correct this now?
 
so I click OK, and then I get another dialogue box saying:

"Errors were encountered changing permissions for the following directories:
/home/xxx : setfacl: /home/xxx: Operation not supported"

Note that /home/xxx is on an ext4 formatted filesystem.

I then click OK and carry on until I get a dialogue box with:

"Unable to complete install: 'internal error unable to start guest: qemu: could not open disk image /home/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied
'"
And in the details part of that dialogue box:

"Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open disk image /home/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1575, 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/lib64/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/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied

'
"

Note also that:
# ls -ldZ /home/xxx/w32/WindowsXP/
drwxr-xr-x. xxx xxx unconfined_u:object_r:virt_image_t:s0 /home/xxx/w32/WindowsXP/

# ls -lZ /home/xxx/w32/WindowsXP/WindowsXP.iso 
-rw-rw-r--. qemu qemu system_u:object_r:virt_content_t:s0 /home/xxx/w32/WindowsXP/WindowsXP.iso

Version-Release number of selected component (if applicable):
libvirt-client-0.7.1-15.fc12.x86_64
virt-manager-0.8.0-7.fc12.noarch
python-virtinst-0.500.0-5.fc12.noarch
libvirt-python-0.7.1-15.fc12.x86_64
libvirt-0.7.1-15.fc12.x86_64
# rpm -qa | grep qemu
qemu-system-sh4-0.11.0-11.fc12.x86_64
gpxe-roms-qemu-0.9.7-6.fc12.noarch
qemu-common-0.11.0-11.fc12.x86_64
qemu-user-0.11.0-11.fc12.x86_64
qemu-system-x86-0.11.0-11.fc12.x86_64
qemu-system-sparc-0.11.0-11.fc12.x86_64
qemu-system-mips-0.11.0-11.fc12.x86_64
qemu-kvm-0.11.0-11.fc12.x86_64
qemu-system-arm-0.11.0-11.fc12.x86_64
qemu-system-m68k-0.11.0-11.fc12.x86_64
qemu-kvm-tools-0.11.0-11.fc12.x86_64
qemu-img-0.11.0-11.fc12.x86_64
qemu-0.11.0-11.fc12.x86_64
qemu-system-cris-0.11.0-11.fc12.x86_64
qemu-system-ppc-0.11.0-11.fc12.x86_64
Comment 1 Mark McLoughlin 2009-11-20 13:41:23 EST
Thanks for the report

What does:

  $> tune2fs -l $my_home_logical_volume | grep options

show? Is it missing the 'acl' option?

Does 'tune2fs -o acl,user_xattr $my_home_logical_volume' fix it?

See bug #530210
Comment 2 Jonathan Underwood 2009-11-20 14:17:27 EST
(In reply to comment #1)
> Thanks for the report
> 
> What does:
> 
>   $> tune2fs -l $my_home_logical_volume | grep options
> 
> show? Is it missing the 'acl' option?
> 

Aha...

# tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options
Default mount options:    (none)


> Does 'tune2fs -o acl,user_xattr $my_home_logical_volume' fix it?
> 

After running that command:

# tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options
Default mount options:    user_xattr acl


However, I still get the dialogue

"Errors were encountered changing permissions for the following directories:
/home/xxx : setfacl: /home/xxx: Operation not supported"

presumably because /home/xxx is not owned by root (but by xxx). This is probably not a bug I am guessing.

Moving the isntall media iso to /home/root which IS owned by root fixes things and the install happens.


> See bug #530210  

It does seem to be a manifestation of the same problem, yeah.
Comment 3 Mark McLoughlin 2009-11-20 14:27:40 EST
(In reply to comment #2)

> After running that command:
> 
> # tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options
> Default mount options:    user_xattr acl
> 
> 
> However, I still get the dialogue
> 
> "Errors were encountered changing permissions for the following directories:
> /home/xxx : setfacl: /home/xxx: Operation not supported"

You probably need to reboot for it to be mounted with the 'acl option
 
> presumably because /home/xxx is not owned by root (but by xxx). This is
> probably not a bug I am guessing.

No, the issue is that it needs to be readable by the 'qemu' user; after rebooting, it should work fine in your homedir

thanks for the update, marking as a dup of bug #530201

*** This bug has been marked as a duplicate of bug 530210 ***
Comment 4 Jonathan Underwood 2009-11-20 14:35:30 EST
(In reply to comment #3)
> No, the issue is that it needs to be readable by the 'qemu' user; after
> rebooting, it should work fine in your homedir
> 

Right, gotcha, of course. Can't reboot right now to test it, but I am sure you're right.

> thanks for the update, marking as a dup of bug #530201

OK - thanks for taking the time to look at it.

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