Description of problem: It does not seems possible to use virt-manager under Enforcing SELinux, otherwise various avc denials block usage, eg for dnsmasq. How reproducible: every time Steps to Reproduce: 1. run virt-manager under default rawhide install 2. try to install rawhide under virt-manager Actual results: 2. Error dialog after pressing Finish and setting up image file: Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /home/petersen/rawhide.img Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 651, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 845, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.5/site-packages/libvirt.py", line 834, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /home/petersen/rawhide.img Expected results: No error Additional info: qemu can boot images fine by itself so this looks like at virt-manager or selinux-policy issue. AVC denial says: SELinux is preventing the qemu from using potentially mislabeled files (/home/petersen/rawhide.img). 詳細説明: SELinux has denied qemu access to potentially mislabeled file(s) (/home/petersen/rawhide.img). This means that SELinux will not allow qemu to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. アクセスを許可: If you want qemu to access this files, you need to relabel them using restorecon -v '/home/petersen/rawhide.img'. You might want to relabel the entire directory using restorecon -R -v '/home/petersen'. 追加情報: ソースコンテキスト unconfined_u:system_r:qemu_t:s0 ターゲットコンテキ� unconfined_u:object_r:user_home_t:s0 ターゲットオブジェ� /home/petersen/rawhide.img [ file ] Source qemu Source Path /usr/bin/qemu Port <不明> Host dhcp-0-224.bne.redhat.com Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages ポリシー RPM selinux-policy-3.3.1-29.fc9 Selinux 有効化 True ポリシータイプ targeted MLS 有効化 True 強制モード Enforcing プラグイン名 home_tmp_bad_labels ホスト名 dhcp-0-224.bne.redhat.com プラットフォーム Linux dhcp-0-224.bne.redhat.com 2.6.25-0.201.rc8.git4.fc9.x86_64 #1 SMP Sun Apr 6 21:39:00 EDT 2008 x86_64 x86_64 通知カウント 1 First Seen 2008年04月09日 21時39分29秒 Last Seen 2008年04月09日 21時39分29秒 Local ID ed89583d-ce59-4383-9f1f-325261f49829 行番号 生の監査メッセージ host=dhcp-0-224.bne.redhat.com type=AVC msg=audit(1207741169.346:145): avc: denied { getattr } for pid=10158 comm="qemu" path="/home/petersen/rawhide.img" dev=dm-0 ino=3539123 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file host=dhcp-0-224.bne.redhat.com type=SYSCALL msg=audit(1207741169.346:145): arch=c000003e syscall=4 success=no exit=-13 a0=7fff6cee4fb0 a1=7fff6cee25a0 a2=7fff6cee25a0 a3=7fff6cee2310 items=0 ppid=10112 pid=10158 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm="qemu" exe="/usr/bin/qemu" subj=unconfined_u:system_r:qemu_t:s0 key=(null)
setsebool -P allow_unconfined_qemu_transition=0 (Default for F9) This will allow you to run qemu without confinement. If you want to run qemu in a confined mode you need to set the file context to virt_image_t chcon -t virt_image_t /home/petersen/rawhide.img To make this survive a relabel you would need to change the permanent file context # semanage fcontext -a -t virt_image_t /home/petersen/rawhide.img # restorecon /home/petersen/rawhide.img I am not sure that qemu will be allowed to search the /home/peterswen for this file though. /var/lib/libvirt/images is the default location for images, which is supported by SELinux.
Ok thanks. > /var/lib/libvirt/images is the default location for images, which > is supported by SELinux. It would be nice then if virt-manager defaulted to storing images there then, rather than under $HOME.
Yes, virt-manager needs updating to default to the correct location. It already does this for Xen and until now it didn't matter for KVM. So we just need a minor tweak to defaults.
I get this error saving to /mnt/guest/fedora.img regardless of whether the allow_unconfined_qemu_transition value is 1 or 0. It's very likely people will want to save the images elsewhere than /var/lib since they tend to be large. There should be an easier way of allowing this than disabling selinux protection (and the gui needs to support this).
*** Bug 444939 has been marked as a duplicate of this bug. ***
Also, while it is quite reasonable to put disk images in one spot, there is also the issue of where CD images are placed. It isn't clear to the administrator that they must also fall under the same restriction.
virt-manager-0.5.4-4.fc9 has been submitted as an update for Fedora 9
virt-manager-0.5.4-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update virt-manager'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3616
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 447319 has been marked as a duplicate of this bug. ***
virt-manager-0.5.4-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
There is still a bug. Now the default location is /var/lib/libvirt/images, but the SELinux context is wrong: # ll -Z /var/lib/libvirt/images/ -rwxrwxr-x root root unconfined_u:object_r:file_t:s0 CentOS-5.img This causes: Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /var/lib/libvirt/images/CentOS-5.img Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 651, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 845, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.5/site-packages/libvirt.py", line 833, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /var/lib/libvirt/images/CentOS-5.img ' However, if I execute the command from the almighty Dan Walsh above: # chcon -t file_t /var/lib/libvirt/images/CentOS-5.img Then the creation process passes this step and virtual machine boot can start.
Your install must pre-date the correct labelling being present in the policy. New installs certainly get the correct label # semanage fcontext -l | grep libvirt/image /var/lib/libvirt/images(/.*)? all files system_u:object_r:virt_image_t:s0 # rpm -q selinux-policy-targeted selinux-policy-targeted-3.3.1-51.fc9.noarch # ls -dZl /var/lib/libvirt/images/ drwx------ 2 system_u:object_r:virt_image_t:s0 root root 4096 2008-05-09 13:07 /var/lib/libvirt/images/ A simple 'restorecon -R /var/lib/libvirt' will fix it up
There is still a problem with that... As I did not have a lot of space on my root partition, I mounted /var/lib/libvirt/images as another partition. Worked great, I could launch the virtual machine. However, after a reboot, this partition can not be mounted as it has the context virt_image_t and it should be mnt_t in order for SELinux to let the partition be mounted. Looks like there is a conflict here :)
Is someone still looking at this bug ?
No, no-one is looking at it. Don't report new bugs in old tickets which have already been closed. *One* ticket per bug.