Bug 89156 - iptables script uses misleading variable names
Summary: iptables script uses misleading variable names
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: iptables (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i386 Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Ben Levenson
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-18 18:13 UTC by Robert P. J. Day
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-03 09:36:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Robert P. J. Day 2003-04-18 18:13:05 UTC
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

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. read the script

Additional info:

Comment 1 Robert P. J. Day 2003-04-18 19:27:44 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.


Comment 2 Michael Schwendt 2003-04-30 14:36:43 UTC
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.

Comment 3 Michael Schwendt 2003-04-30 16:41:55 UTC
Btw, you reported most of these issues earlier in bug #76712 which you might
want to close because this one contains more details.

Comment 4 Michael Schwendt 2003-05-01 22:18:13 UTC
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.


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.

Comment 5 Thomas Woerner 2003-07-03 09:36:15 UTC
Fixed in the new 1.2.8-4.x version. This version has a new startup script and an
additional config file.

> # Additional iptables modules (nat helper)
> # Default: -empty-
> #IPTABLES_MODULES="ip_nat_ftp"
> # Save current firewall rules on stop.
> # Value: yes|no,  default: no
> # Save current firewall rules on restart.
> # Value: yes|no,  default: no
> # Save rule counter.
> # Value: yes|no,  default: yes
> # Numeric status output
> # Value: yes|no,  default: no

RPM packages for 7.x:

RPM packages for 8.0:

RPM packages for 9:

Note You need to log in before you can comment on or make changes to this bug.