From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; SunOS 5.7 sun4u)
Description of problem:
ipchains is supposed to load a module. Instead its load is conditional on
whether it finds a Red Hat supplied firewall to run in
/etc/sysconfig/ipchains. ipchains is defined as a service and should run
regardless of whether I want to use the supplied ipchains firewall instead
of the firewall I am currently using. (In my case I'm running pmfirewall.)
I don't mind that the service can fail to load and not report an error
(e.g., if you want to run iptables instead), but it definitely should not
fail to load the module just because the file /etc/sysconfig/ipchains
doesn't have a valid firewall in it. It's incorrect to assume that everyone
will want to run the firewall that Red Hat supplies (especially since
pmfirewall is better :-)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: My firewall failed to execute because the ipchains module
did not load.
Expected Results: I should have had a running firewall.
Redhat ipchains and iptables init scripts are all vulnerable to silent failure.
Other distributions seem to have similar vulnerabilities as well. The 2.4.x
kernels...ALL 2.4.x kernels...are incapable of loading both ipchains and
iptables modules at the same time. There is no such thing as a Redhat kernel, or
any kernel, that will allow ipchains modules to be loaded if iptables is
supported via *either* loading iptables module *or* compiling in iptables
support. The converse is also true, there is no such thing as a kernel that will
allow iptables to be supported in any way whatsoever if an ipchains module is
currently loaded or supported via compiled in functionality. ipchains and
iptables are mutually exclusive, period, they *cannot* live together under any
The scripts are a security nightmare because they assume that if the kernel does
not support ipchains or iptables, regardless of whether it really does not
support the feature or if the feature is being pushed aside by a mutually
exclusive load of a competing module, that the user should not have run the
script in the first place, or else does not want to be told about non-existent
features, and will not indicate failure in any way. The only time ipchains or
iptables scripts will tell about failure is if the correct module or support is
already working correctly. The scripts are an extreme danger to security, but
could be fixed by allowing them to report failure regardless of whether it is a
bad rule or whether the module is not loaded. It would be a really good idea if
the ipchains script detected a loaded iptables module and replied [conflict]; if
failure was not due to conflict but due to lacking kernel functionality, e.g.,
if the ipchains.o module got deleted, it would be nice for the failure to report
[unsupported]. As is, both of these failures are being covered up. The iptables
script could do the reverse, and report [conflict] if the ipchains.o module is
loaded, or report [unsupported] if the iptables.o module simply can't be found.
It is not practical to expect the kernel to support both modules under
simultaneous load. This is security flaw in the scripts, not the kernel. Scripts
should never hide failure of a security feature.
No, this is definitely not a bug. The purpose of the included
ipchains initscript is solely for the use of the Red Hat ipchains
firewall tools. It is not and never was intended to be used for
a general mechanism for loading the ipchains module.
There was a bug in Red Hat Linux 7.1 that allowed users to use the
script for this purpose. That bug was fixed.
The proper "Red Hat official defined way" of loading the ipchains
module, or any other kernel modules that are not loaded automatically
by kmod, is for the user to edit /etc/rc.d/rc.modules, creating that
file if necessary, and put in the modprobe commands required to load
the module or modules.
Alternatively, a user can create their own script to do so, such as
"/etc/init.d/pmfirewall" for example.
The two initscripts ipchains and iptables are poorly named, no question.
I don't know who named them that, or what they were thinking at that
time. I would have called them something different myself. Nonetheless,
in either case, this is not a bug.
stimits: Your comment above was not seen when I submitted mine
(mid air collision). Your comment has some valid points to it,
however it is completely an orthogonal issue to the reported bug.
Feel free to file a request for enhancement for the desired
I once did file for it. The reply was:
--- shadow/43708 Sun Oct 7 08:22:37 2001
+++ shadow/43708.tmp.19063 Tue Oct 30 02:01:53 2001
@@ -3,8 +3,8 @@
@@ -52,3 +52,14 @@
deactivated is "not good". There is an extreme need to test
for ipchains failure to activate, whether it is by direct failure,
or by kernel support failure.
+------- Additional comments from email@example.com 2001-10-30 02:16:34 -------
+This is not really a bug, because Red Hat Linux does not support
+user compiled kernels. You're free to compile and use your own
+kernel of course, but problems introduced by doing so, that are
+not reproduceable with the supplied kernels, are not generally
+If you can cause a reproduceable problem by using the Red Hat
+supplied kernel, then it is something worthy of investigating
My request was called "NOT A BUG", and deemed to only be a problem on non-Redhat
kernels. Somehow it got misdiagnosed as being a non-Redhat kernel problem,
though it is clearly a script problem with all kernels.