Bug 89156
Summary: | iptables script uses misleading variable names | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Robert P. J. Day <rpjday> |
Component: | iptables | Assignee: | Thomas Woerner <twoerner> |
Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | Keywords: | FutureFeature |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-07-03 09:36:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Robert P. J. Day
2003-04-18 18:13:05 UTC
while i'm here, i might as well add a couple more observations about the /etc/init.d/iptables script. first, in at least four places that i can see (twice in start(), twice in stop() functions), the script loops through the current tables, say flushing them, then does another explicit flush on the filter table; for example: for i in $chains; do iptables -t $i -F; let ret+=$?; done iptables -F once the loop is done, is there any point in the very next command, which flushes the filter table even though it would seem to have just been flushed? just curious -- it's not wrong, just redundant. next, we have the code for "panic)", which covers all possible table/chain combinations for "Changing target policies to DROP:", but is missing some of them for "Flushing all chains:". and, finally, under "Removing user defined chains:", the first line seems to have a surplus of "iftable"s. Some of the issues with the scripts are due being ported from the ipchains scripts I think. > is there any point in the very next command, which > flushes the filter table even though it would seem to have just been flushed? No. With iptables, the "filter" table is listed in /proc/net/ip_tables_names. Either ipchains or old versions of iptables did not list it, IIRC. > "panic)", [...] but is missing some of them for "Flushing all chains:". See bug #75723. It should have been in there. But as long as it's just the "mangle" table, it's not important. > and, finally, under "Removing user defined chains:", the first line seems to > have a surplus of "iftable"s. Sorry, my typo it seems, most likely due to weird indendation in the scripts (another thing that ought to be fixed). Also related to bug #75723. But it doesn't introduce any risks, because the built-in chains are flushed. Btw, you reported most of these issues earlier in bug #76712 which you might want to close because this one contains more details. After closer investigation:
> is there any point in the very next command, which
> flushes the filter table even though it would seem to have just been flushed?
Yes, there is. At system startup, no netfilter kernel module is loaded at all,
and hence /proc does not list any netfilter tables and with its current
implementation "service iptables stop" would not do anything (apart from
printing [ OK ] several times). Plus, "service iptables save" would fail because
of no tables being active and listed in /proc either. Test case:
service iptables stop
rmmod -r iptable_filter
service iptables stop
service iptables save
That's why it makes sense to flush/clean the filter table explicitly because
that operation would make the kernel autoload at least two netfilter modules and
cause /proc to list the filter table. And that in turn would allow the "service
iptables save" to save something.
(#2)
Additionally, upon updating my iptables fix-packages for Valhalla and Shrike --
rsync://riva.homelinux.org/iptables/ -- I've made the "panic" function always
close all built-in chains in all tables. Red Hat's current implementation uses
the "iftable" helper function which only runs an iptables command when a table
is listed in /proc. Regardless of whether netfilter modules are loaded or not,
"service iptables panic" should always close at least the built-in chains in the
filter table.
Fixed in the new 1.2.8-4.x version. This version has a new startup script and an additional config file. /etc/sysconfig/iptables-config: > # Additional iptables modules (nat helper) > # Default: -empty- > #IPTABLES_MODULES="ip_nat_ftp" > > # Save current firewall rules on stop. > # Value: yes|no, default: no > #IPTABLES_SAVE_ON_STOP="no" > > # Save current firewall rules on restart. > # Value: yes|no, default: no > #IPTABLES_SAVE_ON_RESTART="no" > > # Save rule counter. > # Value: yes|no, default: yes > #IPTABLES_SAVE_COUNTER="yes" > > # Numeric status output > # Value: yes|no, default: no > #IPTABLES_STATUS_NUMERIC="no" RPM packages for 7.x: http://people.redhat.com/twoerner/RPMS/7.x/iptables-1.2.8-4.73.1.i386.rpm http://people.redhat.com/twoerner/RPMS/7.x/iptables-ipv6-1.2.8-4.73.1.i386.rpm http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.73.1.src.rpm RPM packages for 8.0: http://people.redhat.com/twoerner/RPMS/8.0/iptables-1.2.8-4.80.1.i386.rpm http://people.redhat.com/twoerner/RPMS/8.0/iptables-ipv6-1.2.8-4.80.1.i386.rpm http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.80.1.src.rpm RPM packages for 9: http://people.redhat.com/twoerner/RPMS/9/iptables-1.2.8-4.90.1.i386.rpm http://people.redhat.com/twoerner/RPMS/9/iptables-ipv6-1.2.8-4.90.1.i386.rpm http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.90.1.src.rpm |