Hide Forgot
Created attachment 562505 [details] template to build an image Description of problem: if SELinux is enabled then it denies access to /usr/libexec/qemu-kvm when trying to build an image and build FAILED. See the error: .... </devices> </domain> INFO:oz.Guest.UbuntuGuest:Cleaning up guest named Ubuntu x86_64 INFO:oz.Guest.UbuntuGuest:Cleaning up after install Traceback (most recent call last): File "/usr/bin/oz-install", line 152, in <module> libvirt_xml = guest.install(timeout, force_download) File "/usr/lib/python2.6/site-packages/oz/Ubuntu.py", line 145, in install return self._do_install(timeout, force, 0) File "/usr/lib/python2.6/site-packages/oz/Guest.py", line 1441, in _do_install dom = self.libvirt_conn.createXML(xml, 0) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2087, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirt.libvirtError: internal error process exited while connecting to monitor: libvir: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.209.el6.x86_64 libvirt-0.9.4-23.el6.x86_64 oz-0.9.0-0.20120214153956git0b723e5.el6.noarch RHEL6.2 - 2.6.32-220.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. make sure SELinux is enable #setenforce 1 2. run #oz-install -d 4 template.tdl Actual results: SELinux denied access Expected results: SELinux allows access Additional info: I don't know if this bug should be rather opened against /usr/libexec/qemu-kvm. if needed template is attached.
I've run into this same thing. It occurred when I (re)started libvirtd from within Jenkins. Can you do a 'ps -eZ | grep libvirt' and see what it returns? What I saw before is that it has an SELinux context of 'unconfined_u:system_r:unconfined_java_t' instead of 'unconfined_u:system_r:virtd_t' which is what I get when I restart it via SSH. Can you confirm that's a) what you are doing, and b) what you see?
does not happen w/ [root@qeblade30 ~]# rpm -qa | grep oz oz-0.8.0-4.el6.noarch which is currently in brew.. checking w/ Ian to make sure 9.0.0 does not get put in brew for the beta
(In reply to comment #1) > I've run into this same thing. It occurred when I (re)started libvirtd from > within Jenkins. > > Can you do a 'ps -eZ | grep libvirt' and see what it returns? > > What I saw before is that it has an SELinux context of > 'unconfined_u:system_r:unconfined_java_t' instead of > 'unconfined_u:system_r:virtd_t' which is what I get when I restart it via SSH. > > Can you confirm that's a) what you are doing, and b) what you see? before restart of libvirtd # ps -eZ | grep libvirt system_u:system_r:virtd_t:s0-s0:c0.c1023 2453 ? 00:00:03 libvirtd after restart of libvirtd # ps -eZ | grep libvirt unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 8753 ? 00:00:00 libvirtd What strange here is, that it doesn't work only with oz-0.9*.. with oz-0.8* it works...
Martin, How, exactly, are you restarting libvirtd? I believe that starting or restarting via the /sbin/service command should work. Doing it an other way (including by explicitly running the init script from a shell or shell script) may change the security context. In any case, this appears to work for everyone who installs and starts libvirtd and the factory in the "normal way". It is only when we introduce restarts via Jenkins or manually that things start failing, yes?
Martin, As we discussed on the standup call on Monday, this is confirmed to be a result of starting libvirtd outside of the normal boot process resulting in an invalid security context. It has nothing to do with Factory. You had indicated you would close this as NOTABUG and potentially clone it as a bug against libvirtd. I'm closing as NOTABUG.
yeah, I have opened clone (Bug 796608) of this bug, but against libvirtd.