----- Original Message ----- From: "Marc Deslauriers" <marcdeslauriers@xxxxxxxxxxxx>
To: <fedora-legacy-list@xxxxxxxxxx>
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
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
