Bug 791210

Summary: Build (OZ) failed with Permission denied when SELinux is enabled
Product: [Retired] CloudForms Cloud Engine Reporter: Martin Kočí <mkoci>
Component: ozAssignee: Ian McLeod <imcleod>
Status: CLOSED NOTABUG QA Contact: Martin Kočí <mkoci>
Severity: urgent Docs Contact:
Priority: medium    
Version: 1.0.0CC: brad, jlaska, whayutin
Target Milestone: beta3   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 796608 (view as bug list) Environment:
Last Closed: 2012-02-22 16:04:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 796608    
Attachments:
Description Flags
template to build an image none

Description Martin Kočí 2012-02-16 14:07:54 UTC
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.

Comment 1 Brad P. Crochet 2012-02-16 15:00:42 UTC
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?

Comment 2 wes hayutin 2012-02-16 18:10:12 UTC
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

Comment 3 Martin Kočí 2012-02-16 18:54:42 UTC
(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...

Comment 4 Ian McLeod 2012-02-21 15:25:18 UTC
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?

Comment 6 Ian McLeod 2012-02-22 16:04:34 UTC
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.

Comment 7 Martin Kočí 2012-02-23 10:18:45 UTC
yeah, I have opened clone (Bug 796608) of this bug, but against libvirtd.