Hide Forgot
+++ This bug was initially created as a clone of Bug #996776 +++ Description of problem: Various permissions errors occur when launching neutron services/using neutron. I'm assuming that the rename from quantum to neutron broke all of the related selinux policies. All binaries, configs/dirs, usernames etc. have had s/quantum/neutron/ done. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. packstack --allinone 2. . keystonerc_demo 3. nova --boot --image cirros --flavor 1 --nic netid=${id of 'private' network} test 4. ausearch -i -m avc Actual results: Instance gets a DHCP address/No avc errors Expected results: Instance does not get a DHCP address/Lots of avc errors Additional info: --- Additional comment from Terry Wilson on 2013-08-19 11:04:36 EDT --- I should also point out that neutron ships with the quantum-named binaries as well for compatibility reasons for now. So the rules should probably cover both. --- Additional comment from lpeer on 2013-08-21 07:50:05 EDT --- --- Additional comment from Miguel Angel Ajo on 2013-09-04 18:12:05 EDT --- I can confirm this bug in a test environment here. (rdo-havana on CentOS 6.4) The VMs won't receive dhcp response, It can be identified this way also; # grep DHCPDISCOVER /var/log/messages Sep 5 01:28:38 opentron dnsmasq-dhcp[3284]: DHCPDISCOVER(tapa5331882-85) fa:16:3e:96:4d:a3 no address available # tail -f /var/log/messages | grep dnsmasq & # killall -HUP dnsmasq Sep 5 01:32:05 opentron dnsmasq[2148]: read /etc/hosts - 2 addresses Sep 5 01:32:05 opentron dnsmasq[3284]: cleared cache Sep 5 01:32:05 opentron dnsmasq[3284]: cannot read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host: Permission denied Sep 5 01:32:05 opentron dnsmasq-dhcp[3284]: read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host Sep 5 01:32:05 opentron dnsmasq[3284]: cannot read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts: Permission denied Sep 5 01:32:05 opentron dnsmasq-dhcp[3284]: read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts Sep 5 01:32:05 opentron dnsmasq[2148]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Sep 5 01:32:05 opentron dnsmasq-dhcp[2148]: read /var/lib/libvirt/dnsmasq/default.hostsfile as a test I ran dnsmasq as root to check: # ip net exec qdhcp-521717de-5dbe-4756-8ef2-fe17321eeae8 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tapa5331882-85 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host --dhcp-optsfile=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts --dhcp-script=/usr/bin/neutron-dhcp-agent-dnsmasq-lease-update --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,120s --conf-file= --domain=openstacklocal and it works --- Additional comment from Lon Hohberger on 2013-09-10 09:55:01 EDT --- This patch was rejected, but is included for reference. --- Additional comment from Lon Hohberger on 2013-09-10 09:58:10 EDT ---
Created attachment 796020 [details] Patch from upstream which resolves the problem
Created attachment 796034 [details] Untested backport
Side note: we do want contexts for both Quantum and Neutron at the same time - Dan's original patch and my backport attempt to do this.
We also had this in the existing openstack-selinux policy: https://github.com/lhh/openstack-selinux/blob/master/openstack-selinux-quantum.te Perhaps these small fixes could be merged.
Created attachment 799561 [details] Tested backport
Test repository: http://people.redhat.com/lhh/selinux-policy/
Miroslav also did a build for this; I'll update the repository with his patch/build.
Has been already added.
Following 3 types were not renamed. Is it expected? # rpm -qa selinux-policy\* selinux-policy-doc-3.7.19-228.el6.noarch selinux-policy-mls-3.7.19-228.el6.noarch selinux-policy-minimum-3.7.19-228.el6.noarch selinux-policy-3.7.19-228.el6.noarch selinux-policy-targeted-3.7.19-228.el6.noarch # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted # for I in -t -a -r -u -b -c --portcon ; do seinfo $I | grep -i quantum ; done quantum_port_t quantum_server_packet_t quantum_client_packet_t portcon tcp 9696 system_u:object_r:quantum_port_t:s0 #
We probably should rename them and add appropriate alias.
Yes but I don't see as a big problem in RHEL6.5 now.
3d3549c0bdd84af83fe6d1f4f3c9379e65a8f73a 5648a674bcbedaaf89317cde3a2f38a2b206543f Fix this in git. Miroslav we should rename the module in F20 also.
I filed the last mentioned issue as a separate Bug 1024927.
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. http://rhn.redhat.com/errata/RHBA-2013-1598.html