Bug 523960

Summary: virtinst saves images where qemu can't access them by default
Product: [Fedora] Fedora Reporter: Michal Nowak <mnowak>
Component: python-virtinstAssignee: Daniel Berrange <berrange>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: high    
Version: rawhideCC: berrange, crobinso, dwalsh, emcnabb, markmc, ohudlick, petersen, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-01 10:22:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 498969    

Description Michal Nowak 2009-09-17 08:31:00 EDT
Description of problem:

Following scenario "virt-install w/ qcow2" from https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization_qcow2 I got this traceback:

newman@dhcp-lab-124 SPECS $ virt-install --connect qemu:///system              --name rawhide-qcow2              --ram 1024              --disk path=/var/lib/libvirt/images/rawhide.qcow2,format=qcow2,size=6              --location http://download.englab.brq.redhat.com/pub/fedora/linux/development/x86_64/os              --os-variant fedora12


Starting install...
Retrieving file .treeinfo...                             | 2.4 kB     00:00 ... 
Retrieving file vmlinuz...                               | 7.1 MB     00:00 ... 
Retrieving file initrd.img...                            |  45 MB     00:01 ... 
Allocating 'rawhide.qcow2'                               |    0 B     00:00     
ERROR    internal error unable to start guest: char device redirected to /dev/pts/2
qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU'

Domain installation may not have been
 successful.  If it was, you can restart your domain
 by running 'virsh start rawhide-qcow2'; otherwise, please
 restart your installation.
ERROR    internal error unable to start guest: char device redirected to /dev/pts/2
qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU'
Traceback (most recent call last):
  File "/usr/bin/virt-install", line 933, in <module>
    main()
  File "/usr/bin/virt-install", line 829, in main
    start_time, guest.start_install)
  File "/usr/bin/virt-install", line 884, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  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: char device redirected to /dev/pts/2
qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.VjmKwU'


When run as ordinary user.

Version-Release number of selected component (if applicable):

python-virtinst-0.500.0-3.fc12.noarch
libvirt-0.7.1-1.fc12.x86_64
Linux dhcp-lab-124.englab.brq.redhat.com 2.6.31-14.fc12.x86_64 #1 SMP Tue Sep 15 03:48:57 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:

well, always

Steps to Reproduce:
1. run the command
2. 
3.
  
Actual results:

backtrace

Additional info:

SELINUX=permissive
SELINUXTYPE=targeted

But not AVC seen.
Comment 1 Michal Nowak 2009-09-17 08:43:58 EDT
Just noticed with virt-manager too.

Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: char device redirected to /dev/pts/2
qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.CZ8Rrp'

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/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: char device redirected to /dev/pts/2
qemu: could not load kernel '/home/newman/.virtinst/boot/virtinst-vmlinuz.CZ8Rrp'

'
Comment 2 Mark McLoughlin 2009-09-17 08:47:16 EDT
Okay, we need to fix this

As a workaround, you need to do:

 $> chmod 0+x /home/newman/ /home/newman/.virtinst /home/newman/.virtinst/boot/

so that qemu can get at the images
Comment 3 Mark McLoughlin 2009-09-17 08:53:06 EDT
Suggestion is that virtinst should use something like /tmp/virst-$user/boot instead since we can't control the permissions of /home/$user
Comment 4 Cole Robinson 2009-09-21 13:12:42 EDT
adding dwalsh

What will we have to do wrt to selinux for this? Previously the selinux policy could point to the known location ~/.virtinst/boot, which we could restorecon. How will tmp work in that respect? Are there any security implications of using /tmp over /home?
Comment 5 Daniel Walsh 2009-09-21 22:48:56 EDT
Cole what is the behaviour of virt-install supposed to be here?  Is this run as root?  We can label in these different location, but what is the fundamental problem here, since it does not seem to be an SELinux problem yet.
Comment 6 Cole Robinson 2009-09-22 12:18:29 EDT
Libvirt now runs qemu process as the 'qemu' user (previously as 'root), which doesn't have search permissions for the average user's home directory. This breaks URL installs via virt-install, because we download the kernel/initrd to ~user/.virtinst/boot by default. Whatever user we run virt-install as doesn't affect the what user the qemu binary is run as.

It is suggested that we change this URL download location to something under /tmp, and I was curious what selinux policy changes would need to made to accomodate that. Currently ~/.virtinst/boot is referenced in the selinux-policy AFAIK.
Comment 7 Daniel Walsh 2009-09-22 20:52:13 EDT
The assumption that /tmp is the same for the user QEMU is the same as dwalsh is a faulty assumption.

This is virt-manager/virt-install running as dwalsh downloading a file and then tells libvirt to launch a qemu running as UID qemu to read the file?

Is this your framework.  We cannot cp the file into a directory controlled by libvirt, because of size?
Comment 8 Daniel Berrange 2009-09-23 04:35:18 EDT
I don't much like the idea of moving stuff back into /tmp again - $HOME/.virtinst was a good move to make.  

I think perhaps we should make use of ACLs, and set an xplicit ACL

   qemu+x

On $HOME  when we store data there that QEMU needs to use. This is better than simply chmoding  o+x, because it is restricted to just the QEMU user, and it is obvious why the change was made & thus trivially reverted
Comment 9 Daniel Walsh 2009-09-23 10:52:28 EDT
That sounds ok with me and would not need to change any policy, but is a user allowed to do this?

setfacl -m u:qemu:x virt-clone.log 
setfacl: virt-clone.log: Operation not permitted
[Exit 1]

Or are you going to have libvirt do this?
Comment 10 Cole Robinson 2009-09-24 11:20:58 EDT
(In reply to comment #9)
> That sounds ok with me and would not need to change any policy, but is a user
> allowed to do this?
> 
> setfacl -m u:qemu:x virt-clone.log 
> setfacl: virt-clone.log: Operation not permitted
> [Exit 1]
> 

Not sure why that doesn't work, it works fine for me.

> Or are you going to have libvirt do this? 

No, virtinst will be doing it.

This should be working in virtinst-0.500.0-4: we will use setfacl to try and correct these permissions. Testing is appreciated since there still be problems.
Comment 11 Cole Robinson 2009-09-24 11:32:53 EDT
*** Bug 522710 has been marked as a duplicate of this bug. ***
Comment 12 Mark McLoughlin 2009-10-01 10:22:47 EDT
Let's assume that fixed it :-)

* Thu Sep 24 2009 Cole Robinson <crobinso@redhat.com> - 0.500.0-4.fc12
- Fix path permissions for kernel/initrd download location (bz 523960)

Folks, please do re-open if you still see this issue