Hide Forgot
Description of problem: After having updated some nodes to 7.3 (but not rebooted) , ip6tables service doesn't (re)start as it has invalid context on the /var/lock/subsys/ip6tables Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-102.el7_3.7.noarch iptables-services-1.4.21-17.el7.x86_64 How reproducible: Have a el7.2 updated to 7.3, including a bump from those pkgs to newer versions: selinux-policy-targeted-3.13.1-102.el7_3.7.noarch => selinux-policy-targeted-3.13.1-102.el7_3.7.noarch iptables-services-1.4.21-16.el7.x86_64 => iptables-services-1.4.21-17.el7.x86_64 Actual results: systemctl start ip6tables => fails Expected results: ip6tables service would succeed Additional info: on el7.2, the context for /var/lock/subsys/ip6tables was : -rw-r--r--. root root system_u:object_r:var_lock_t:s0 ip6tables But it's now denied, so putting it to iptables_lock_t (like for iptables service) allow the service to start Interesting : restorecon -Rv /var/lock/subsys/ip6tables restorecon: Warning no default label for /run/lock/subsys/ip6tables But a reboot seem to solve that issue (but rebooting a bunch of servers isn't the best idea either)
There has been no change in the iptables init script related to the subsys lock file path since 2004.
Reassigning to selinux-policy.
I believe this bug describes another aspect of the same problem as BZ#1376343 or BZ#1367520. # matchpathcon /var/lock/subsys/iptables /var/lock/subsys/iptables system_u:object_r:iptables_lock_t:s0 # matchpathcon /var/lock/subsys/ip6tables /var/lock/subsys/ip6tables <<none>> #
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/RHBA-2017:1861