Bug 523960
| Summary: | virtinst saves images where qemu can't access them by default | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Nowak <mnowak> |
| Component: | python-virtinst | Assignee: | Daniel Berrangé <berrange> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | 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 14:22:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 498969 | ||
|
Description
Michal Nowak
2009-09-17 12:31:00 UTC
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'
'
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 Suggestion is that virtinst should use something like /tmp/virst-$user/boot instead since we can't control the permissions of /home/$user 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? 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. 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. 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? 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 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? (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. *** Bug 522710 has been marked as a duplicate of this bug. *** Let's assume that fixed it :-) * Thu Sep 24 2009 Cole Robinson <crobinso> - 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 |