Re: condition for 2.6.16

[Amin Azez <azez@ufomechanic.net>]

Gerd v. Egidy wrote:
> On Friday 21 April 2006 01:26, Massimiliano Hofer wrote:
> 
>>On Friday 21 April 2006 12:47 am, Patrick McHardy wrote:
>>
>>>It was discussed at the netfilter workshops, summaries are available at
>>>workshop.netfilter.org.
>>
>>I did a cursory check of the site, but I only found a 5 or 6 lines summary
>>for every conference. Google doesn't help either.
>>May you direct me to a more comprehensive report, please?
> 
> 
> There is no big discussion about condition online but one line at 
> http://workshop.netfilter.org/2004/ :
> 
> 6.2. Decisions about individual patches
> ...
> condition  Stays in POM, because it's ugly and ruleset updates are faster 
> these days 

I like it's "ugliness"

> I don't know more than that because I didn't attend that netfilter workshop.
> 
> I already had a discussion about the future of condition with Harald back in 
> 2004 and he basically said the same as Patrick now:
> 
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/5694
> 
> I think something like condition is needed as temporary solution until the 
> proposed fast and reliable way to change rules is available. I very much 
> appreciate your work on porting it to 2.6, I already had planned doing that 
> in the nex two or three month.

ipt_condition allows the abstraction of enabling/disabling features of 
an iptables ruleset.

If you remove a rule, you have destroyed the information as to where in 
the ruleset it belonged. Removing a rule is conceptually different from 
disabling it.

One exaple is use of ipt_redirect to a trasparent web proxy, the rule 
exists among a sequence of rules as not all users should have their 
traffic via the proxy depnding on source-ip/target-ip combinations as 
well as marks (from other rules) and then ipt_condition to enable or 
disable the interception.

To remove the intercept rule is to lose the prioritisation information.
It could be implemented via sub-chains, which is to my mind more messy.

I will say that ipt_condition will not go away. The code is simple 
enough, the only objection I find is that one if its uses is to overcome 
a deficiency in iptables management tools. It may stay in pom, but it 
provides too useful an interface to go away.

Sam