Bug 27962 - initscript should reset all tables, not just filter
Summary: initscript should reset all tables, not just filter
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: iptables   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-16 11:43 UTC by Ben Liblit
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-24 01:44:07 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 Ben Liblit 2001-02-16 11:43:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i586)

The /etc/rc.d/init.d/iptables initscript goes to considerable lengths to
flush/clear/reset the INPUT, OUTPUT, and FORWARD chains in the "filter"
table.  However, this is not the only table!  Systems doing masquerading
will also be using the "nat" table.  Systems doing packet rewriting will
also be using the "mangle" table.  Additional tables might appear in the
future, or in certain local configurations.

Reproducible: Always
Steps to Reproduce:
1. service iptables stop
2. iptables -t nat -A POSTROUTING -j ACCEPT
3. service iptables stop
4. iptables -t NAT -L POSTROUTING

Actual Results:  Output from the final "iptables ... -L ..." command shows
that there is still a rule on the POSTROUTING chain in the "nat" table:

	target     prot opt source               destination
	ACCEPT     all  --  anywhere             anywhere

Expected Results:  The second "service iptables stop" command should have
cleared out *all* tables.  The output from the final "iptables ... -L ..."
command should have showed an empty POSTROUTING chain in the "nat" table:

	target     prot opt source               destination

The most general solution here is to not hard-wire the list of tables into
the script.  Rather, the script should read "/proc/net/ip_tables_names",
which will always be a newline-delimited list of tables active in the
kernel at that moment.

Flushing all rules in all chains in all tables should be easy enough with
something like the following:

	for table in `cat /proc/net/ip_tables_names`; do
	  iptables -t $table -F

What's less obvious is how to reset all chains to their default policies. 
The "/proc/net/ip_tables_names" file makes it easy to avoid hard-wiring the
list of tables, but I'm not sure how to avoid hardwiring the list of
built-in chains for each table.

Comment 1 Glen Foster 2001-02-17 22:39:38 UTC
We (Red Hat) should really try to resolve this before next release.

Comment 2 Jay Berkenbilt 2001-02-19 18:22:38 UTC
One suggestion on how to avoid hardcoding the list of chains for each table
would be to parse the output of iptables -L if we're willing to rely on that....

Comment 3 Ben Liblit 2001-02-24 01:34:51 UTC
The scripts seem to have been updated for wolverine.  Now the scripts assume
that the "filter", "nat", and "mangle" tables are always present.  That's just
as bad in the opposite direction.  What if I don't have all of those tables in
my kernel?  What if I have some additional tables defined by locally created

The init scripts cannot hard wire a list of tables, period.  They must discover
the list of tables by looking at "/proc/net/ip_tables_names", as I suggested in
my original bug report.

This bug report is already tagged "fisher".  Should I submit a new bug report
against wolverine?

Comment 4 Ben Liblit 2001-02-24 01:44:03 UTC
Looks like bug #29104 already describes this new wolverine issue.  Disregard my
question about filing a new report.

Comment 5 Bernhard Rosenkraenzer 2001-02-27 17:57:06 UTC
Fixed in 1.2.0-9

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