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):
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
systemctl start ip6tables => fails
ip6tables service would succeed
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
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
# matchpathcon /var/lock/subsys/ip6tables
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.