Hide Forgot
+++ This bug was initially created as a clone of Bug #791210 +++ 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. --- Additional comment from brad on 2012-02-16 10:00:42 EST --- 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? --- Additional comment from whayutin on 2012-02-16 13:10:12 EST --- 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 --- Additional comment from mkoci on 2012-02-16 13:54:42 EST --- (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... --- Additional comment from imcleod on 2012-02-21 10:25:18 EST --- 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? --- Additional comment from imcleod on 2012-02-22 11:04:34 EST --- 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. ------------------------- I'm opening this against libvirtd. I will provide further information once I'm sure about what it causes.
Based on the discussion in BZ 791210 it appears that the process that's spawning libvirtd is doing so with the wrong context, so I don't think that there's anything that libvirt can do to help. Jiri, am I right about that?
Just a small update.. If libvirtd is restarted from HUDSON/JENKINS, then you reproduce the issue and you get this context: unconfined_u:system_r:unconfined_java_t:s0-s0:c0.c1023 root 30469 1 0 Feb23 ? 00:00:00 libvirtd --daemon Then if you restart libvirtd from command line you get this context (which works) unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 root 10905 1 6 07:26 ? 00:00:00 libvirtd --daemon
Yeah, we can't do much when we are started with a wrong context. It's up to the parent to execute libvirtd with the right context either explicitly or by using service {re,}start libvirtd which would do the right thing. But only if selinux-policy allows the parent to do so, of course.
Jiri, given what you've said, I think it's pretty clear there is nothing libvirt can do about this situation and this is not a libvirt bug, but what does Martin need to do to resolve his problem? I.e, what component should this be changed to?
I don't know to be honest. From comment 2, it seems it's HUDSON/JENKINS messing up with libvirtd. So this would need to be fixed there.
To be more precise: There is os.system(service libvirtd restart) line in the python script which is triggered from HUDSON/JENKINS. This causes change of the context to unconfined_u:system_r:unconfined_java_t
I see, I'm not sure how exactly service changes the contexts but I guess it can only do so if executed within a context that allows it do so. That is, it's likely service command run in unconfined_u:system_r:unconfined_java_t context is not allowed to set the right context when calling init scripts. Which is a good thing. So one possible way to fix this issue would be to stop messing with services. (Why do you need to restart libvirtd anyway?) Otherwise you can try talking to selinux-policy guys to check if my understanding is correct and if anything can be done to allow your use case.
Ok, thanks; I'm going to close as not a bug. Martin, if you'd like further input from the project, please mail the upstream list (libvir-list)
I'm OK with that.