From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: the service script /etc/init.d/iptables uses a very poor choice of variable name to represent the current tables. in the start() segment, we have the line chains=`cat /proc/net/ip_tables_names ...` but the output represents the *tables*, not the chains, which as we all know are a different component of iptables. for the same reason, the subsequent "for" loop looks weird, since it loops through the elements of $chains, and runs a command that clearly is processing table names. just changing that variable name to "tables" would make this script easier to peruse. Version-Release number of selected component (if applicable): 1.2.7a-2 How reproducible: Always Steps to Reproduce: 1. read the script 2. 3. Additional info:
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