Bug 1494907
Summary: | Unable to launch nova instance: Instance failed to spawn: libvirtError: internal error: process exited while connecting to monitor: libvirt: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Alexander Chuzhoy <sasha> | ||||
Component: | openstack-selinux | Assignee: | Lon Hohberger <lhh> | ||||
Status: | CLOSED ERRATA | QA Contact: | Alexander Chuzhoy <sasha> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 12.0 (Pike) | CC: | apevec, aschultz, dbecker, fbaudin, lyarwood, mbooth, mburns, mcornea, mgrepl, morazi, rhallise, rhel-osp-director-maint, sasha, sgordon, srevivo, supadhya, tvignaud, yprokule | ||||
Target Milestone: | rc | Keywords: | Triaged | ||||
Target Release: | 12.0 (Pike) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | openstack-selinux-0.8.10-0.20170922165741.52b3fe8.4.el7ost | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1496453 (view as bug list) | Environment: | |||||
Last Closed: | 2017-12-13 22:11:04 UTC | Type: | Bug | ||||
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: | 1438937, 1496453 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Alexander Chuzhoy
2017-09-24 04:12:38 UTC
We need the whole audit.log from a permissive run here - the call trace is important to determine what is going on. Okay, so the grep there is from the iptables-service package: grep -qIsE "^install[[:space:]]+${_IPV}[[:space:]]+/bin/(true|false)" /etc/modprobe.conf /etc/modprobe.d/* So, starting ip6tables causes it to grep everything in /etc/modprobe.d/*. This needs an audit rule, but I don't think this is causing instances to fail to launch. spc_t is super-privileged container: https://danwalsh.livejournal.com/74754.html So, this is likely our openstack-nova-libvirt-docker (which contains libvirt and qemu-kvm[-rhev]) trying to launch an svirt instance in the host. Created attachment 1331220 [details]
audit.log from compute.
https://paste.fedoraproject.org/paste/xCqXruE6w-4yem-HimjZfw Fix for the domain transition issue; will be fixed in container-selinux 2.25 Included workarounds here: openstack-selinux-0.8.10-0.20170922165741.52b3fe8.4.el7ost This includes these two patches (until we have a new container-selinux build), and various other rules to allow operation of spc_t -> svirt_t transition and support: https://github.com/projectatomic/container-selinux/commit/947f3a996bd154b524d69e0ea094f09e098b6fad https://github.com/projectatomic/container-selinux/commit/efaffbd8fa3f304c2b90d36c32d35fd9b03860bf For this patch to go upstream to openstack-selinux, RDO needs to add container-selinux to -common at at least version 2.21, or I will have to make some sort of RHEL detection in the RDO master and Pike spec files to avoid using interfaces from container-selinux. Note that changes in container-selinux are still forthcoming; these workarounds should work until they are complete, at which point, they can hopefully be discarded. > RDO needs to add container-selinux to -common at at least version 2.21 container-selinux is in Extras repo, latest on CentOS 7.4 machine is: Updating: container-selinux noarch 2:2.21-2.gitba103ac.el7 extras 29 k built 2017-09-21 > or I will have to make some sort of RHEL detection in the RDO master and Pike spec files to avoid using interfaces from container-selinux. no need Excellent. Verified Environment: openstack-selinux-0.8.11-0.20171103171618.ce13ba7.el7ost.noarch The issue doesn't reproduce. Was able to launch instances without disabling selinux on compute nodes. My issue was related to an overcloud customization that changed SELinux permissions of /etc/ld.so.cache. "restorecon -v /etc/ld.so.cache" fixed the issue. So confirming that the bug is fixed for me. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462 |