"[FLSA-2005:2252] Updated iptables packages resolve security issues" introduces new bug

[Bart Westra]

----- Original Message ----- 
From: "Marc Deslauriers" <marcdeslauriers at videotron.ca>
To: <fedora-legacy-list at redhat.com>
Sent: Sunday, February 20, 2005 2:19 PM
Subject: Re: "[FLSA-2005:2252] Updated iptables packages resolve security 
issues" introduces new bug

ip_nat_ftp and ip_conntrack_ftp never load by themselves. They have to
be manually loaded. The problem here, is we upgraded the iptables
version to the newer version that Red Hat released for rh 7.3 instead of
just patching the current version. The newer version has an updated init
script. The new init script explicitly unloads all loaded modules at
startup. This changes the previous rh9 behaviour. If people were loading
the modules manually before the init script came up, the update
essentially broke their firewall.

Another case that proves backporting is better than updating versions...

Do you guys have any bugs besides your modules not loading anymore?

Marc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Well as far as I can tell, the firewall is running ok now.

But althought the result is working, that new init script is only lucky to 
do so. The rmmod_r function is set up to work recursively, but it uses 
global variables for mod, ret, ref and i. I have put in a patch to display 
what modules are actually being stopped and can see it fails to remove 
modules that are referred to by others, i.e. when a recursive call is done. 
Still after an iptables stop, all modules related to iptables are gone...
Also, the stopping of ip_conntrack_ftp takes a long time, at least one 
minute.

What I have done now as a test is:
- added a 'local'  declaration for mod, ret, ref and i in the rmmod_r 
function
- commented out the stopping of ip_conntrack in the stop function

Now reloading to apply new firewall rules is fast and doesn't break my ssh 
connection to the box. Question is if the original bug is still fixed with 
these changes?

Regards
Bart