Bug 1311919 - deployment failed - Neutron server failed to start due to SELinux block
deployment failed - Neutron server failed to start due to SELinux block
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-selinux (Show other bugs)
7.0 (Kilo)
x86_64 Linux
urgent Severity high
: async
: 7.0 (Kilo)
Assigned To: Ryan Hallisey
Udi Shkalim
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 05:38 EST by Yogev Rabl
Modified: 2016-10-12 16:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-12 16:04:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
neutron server log (12.40 KB, text/plain)
2016-02-25 05:38 EST, Yogev Rabl
no flags Details

  None (edit)
Description Yogev Rabl 2016-02-25 05:38:03 EST
Created attachment 1130467 [details]
neutron server log

Description of problem:
A deployment of 1 controller, 2 computes and 1 Ceph storage node failed when the Neutron server failed to start on the controller with an error (see attachment of the server log), the root cause is showed in the audit.log: 

type=AVC msg=audit(1456396196.701:11469): avc:  denied  { getattr } for  pid=2094 comm="awk" path="/etc/ld.so.cache" dev="vda2" ino=12205389 scontext=system_u:system_r:ksmtuned_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file

The service neutron-server.service ran successfully after I set SELinux to permissive.


Version-Release number of selected component (if applicable):
openstack-neutron-2015.1.2-9.el7ost.noarch
selinux-policy-3.13.1-60.el7_2.3.noarch
openstack-tripleo-image-elements-0.9.6-10.el7ost.noarch
openstack-tripleo-0.0.7-0.1.1664e566.el7ost.noarch
openstack-tripleo-common-0.0.1.dev6-6.git49b57eb.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.1-5.el7ost.noarch
openstack-tripleo-heat-templates-0.8.6-122.el7ost.noarch

How reproducible:
unknown

Steps to Reproduce:
1. Deploy the overcloud with SELinux on enforcing 

Actual results:
The deployment failed - neutron server failed to start

Expected results:
The deployment finished successfully with all of OSP services up and running

Additional info:
Comment 2 Ryan Hallisey 2016-02-25 07:57:35 EST
This is a strange AVC. KSM has to do with shared memory between VMs. Can you give me the audit.log after running in permissive?  I think there's something else causing this.
Comment 3 Alexander Chuzhoy 2016-02-25 14:39:19 EST
Didn't reproduce this on HA deployment:
All the resources are shows as started
Environment:
openstack-tripleo-0.0.7-0.1.1664e566.el7ost.noarch
selinux-policy-devel-3.13.1-60.el7_2.3.noarch
libselinux-python-2.2.2-6.el7.x86_64
libselinux-2.2.2-6.el7.x86_64
openstack-tripleo-heat-templates-0.8.6-122.el7ost.noarch
openstack-tripleo-common-0.0.1.dev6-6.git49b57eb.el7ost.noarch
openstack-tripleo-image-elements-0.9.6-10.el7ost.noarch
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-devel-2.2.2-6.el7.x86_64
openstack-selinux-0.6.46-1.el7ost.noarch
libselinux-ruby-2.2.2-6.el7.x86_64
openstack-tripleo-puppet-elements-0.0.1-5.el7ost.noarch
selinux-policy-3.13.1-60.el7_2.3.noarch
instack-undercloud-2.1.2-39.el7ost.noarch
selinux-policy-targeted-3.13.1-60.el7_2.3.noarch
Comment 4 Alexander Chuzhoy 2016-02-25 15:17:03 EST
Didn't reproduce on nonHA deployment.
openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 --ceph-storage-scale 1   --ntp-server x.x.x.x --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e network-environment.yaml
Comment 5 Lon Hohberger 2016-02-25 15:59:16 EST
Like Ryan says, there's something else going on -

type=AVC msg=audit(1456396196.701:11469): avc:  denied  { getattr } for  pid=2094 comm="awk" path="/etc/ld.so.cache" dev="vda2" ino=12205389 scontext=system_u:system_r:ksmtuned_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file

Why is awk running as ksmtuned_t and what's its business with ld.so.cache?

None of these contexts or applications are directly related to OpenStack.
Comment 6 Lon Hohberger 2016-02-25 16:00:03 EST
Also, ld.so.cache has the wrong label.  Try 'restorecon /etc/ld.so.cache' as well.
Comment 7 Yogev Rabl 2016-02-28 04:52:42 EST
(In reply to Ryan Hallisey from comment #2)
> This is a strange AVC. KSM has to do with shared memory between VMs. Can you
> give me the audit.log after running in permissive?  I think there's
> something else causing this.

I'll reproduce it later on this week (I moved to a different version) and will provide you the audit.log
Comment 8 Mike Burns 2016-10-12 16:04:37 EDT
No response in 7+ months, please reopen if you reproduce

Note You need to log in before you can comment on or make changes to this bug.