Description of Problem:
When using a kernel without ipchains enabled, the script in
fails to correctly identify ipchains rules as failed. There is no
whatever during normal boot messages of ipchains failure.
Install any kernel without ipchains support. Despite failure, due to
kernel not supporting ipchains, absolutely no indication is given of
this failure. The only indication is manually running /sbin/ipchains.
Steps to Reproduce:
1. Install a 2.4.x series kernel that does not work with ipchains.
2. View bootup messages, no indication of failure.
ipchains rules will appear to be activated, or at least will not
make any indication of failure.
If ipchains in /etc/rc.d/init.d/ipchains is run with any argument of
start, stop, or status, and the kernel does not support ipchains,
or for ANY reason ipchains does not succeed, a big fat RED
FAIL message should appear.
Manually running "ipchains -L" can produce, from 2.4.x kernels:
ipchains: Incompatible with this kernel
Due to the number of weaknesses in a system without firewall,
and after checking logs, it probably requires a complete system
reinstall after having been on the Internet for only a few hours.
Failure to inform correctly about security measures being
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.
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
This is a problem of scripts that do not check return values, and is independent
of kernel, other than being 2.4.x series. If a RH kernel has iptables module
loaded, it likely will behave the same way. I am running XFS filesystem on my
root partition, so I can't check this without reformatting my whole system, and
I am not willing to do this. Other people I have talked to believe the problem
is with scripts that fail to check all return values. The bug report may be
closed, but I believe the bug continues to exist.