why does ifup-eth script set the firewall zone

[erickj]

Hi,

I've been trying to learn new centos 7 systemd and firewalld concepts over the past few days and came across this one today when rebooting my server.

i had previously setup firewalld and placed eth0 and eth1 in the dmz and internal zones respectively w/ the following commands:

Code: Select all

sudo firewall-cmd --permanent --zone=public --remove-interface=eth1
sudo firewall-cmd --permanent --zone=internal --add-interface=eth1

on reboot I looked at the active zones and saw both devices were back in the public zone. after digging for a while I realized it was due to the following code in the /etc/sysconfig/network-scripts/ifup-eth and ifup-post scripts:

Code: Select all

# Inform firewall which network zone (empty means default) this interface belongs to
if [ -x /usr/bin/firewall-cmd -a "${REALDEVICE}" != "lo" ]; then
    /usr/bin/firewall-cmd --zone="${ZONE}" --change-interface="${DEVICE}" > /dev/null 2>&1
fi

so this effectively makes any "permanent" zone changes like the one I made above permanent across firewalld restarts, but not machine restarts or interface up/down cycles.

I added the ZONE setting to each device's config to fix my issue for now...

but my question is, why is this done at all? the "default" ZONE value blows away the permanently set value. it seems like the script should at least check the current value of

Code: Select all

firewall-cmd --get-zone-of-interface=eth0

and use that over ZONE?

[TrevorH]

I don't know how this is meant to operate but to me, that sounds like a bug that needs to be reported on bugzilla.redhat.com. You can also raise a centos bug on bugs.centos.org and crosslink the two.

[erickj]

for reference, reported here http://bugs.centos.org/view.php?id=7526

[TrevorH]

Raising bugs on bugs.centos.org lets the CentOS devs know. Redhat don't look at it and they are the people that would either fix this or tell you if it is a bug or not.

[jlehtone]

but my question is, why is this done at all? the "default" ZONE value blows away the permanently set value. it seems like the script should at least check the current value

I bet this is one of the many cases where left hand has no idea of what the right hand does. In other words, the maintainers of ifup-scripts and firewalld have not agreed on responsibilities.

The ifup clearly assumes that on case of "default" the firewalld does the "right thing". However it doesn't trust the firewalld enough and makes a call even though config does not have overriding ZONE.
The firewalld-cmd assumes that if it is called, then the caller does the "right thing".

Both can blame the other. What is the stand of the infamous NetworkManager regarding this dispute?


From the viewpoint of ifup(-user) it is really coherent to have all config in one place (the ifcfg-*). (The el5 had ifup renaming interfaces, but the el6 ifup finally gave up that task to udev.)
On the other hand, it makes sense to define all firewalld-stuff in one place.
(There are strong opinions about NM and its "one place" too, but they are mostly unprintable.)


Therefore, this is a policy issue: Who should do what? Once that has been agreed, each should fix their part.

As TrevorH said, that is an upstream (Redhat) issue.