Red Hat Bugzilla – Bug 1406860
restorecon location in /usr/libexec/iptables/iptables.init in assumed incorrectly
Last modified: 2018-04-10 07:28:02 EDT
As part of Bug #1246380, a check was introduced to ensure restorecon was available. The check that has been introduced assumes restorecon is available at /bin/restorecon. See lines 32-33 of /usr/libexec/iptables/iptables.init: RESTORECON=/bin/restorecon [ ! -x "$RESTORECON" ] && RESTORECON=/bin/true This means for systems with restorecon at a different location (such as /sbin/restorecon), restorecon is never ran against stored iptables data, resulting in an error when starting iptables if data had previously been stored with an incorrect context: "iptables: Applying firewall rules: Can't open /etc/sysconfig/iptables: Permission denied" This was introduced in iptables-services-1.4.21-17.el7.x86_64 # rpm -q iptables-services iptables-services-1.4.21-17.el7.x86_64
OK, so my proposed solution is to use which: RESTORECON=$(which restorecon) This works fine, but only after adjusting selinux policies. After loading the following module into the kernel, everything works fine: module iptables.init_restorecon 1.0; require { type setfiles_exec_t; type iptables_t; class file { execute getattr }; } #============= iptables_t ============== allow iptables_t setfiles_exec_t:file { execute getattr };
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-2018:0715