condition and 2.6

condition and 2.6

[Gerd v. Egidy]

Hi Harald,

I'm currently using the condition match on a lot of 2.4 machines. I use it to 
differentiate between primary provider/secondary provider, remote 
administration on/off,... 
I like it very much because I don't need to change the rules themselves in a 
live production environment anymore and can therefore make my scripts much 
more rule-independant.

Now I was playing around a bit with 2.6 and found the following comment from 
you in cvs: "made it 2.4.x only, since I don't like it anyway."

What do you dislike? Is it the idea or the implementation? Do you know of any 
bugs or possible problems in the code - especially with 2.6?

Kind regards,

Gerd

Re: condition and 2.6

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Sun, Feb 29, 2004 at 02:10:35AM +0100, Gerd v. Egidy wrote:
> Hi Harald,
> 
> I'm currently using the condition match on a lot of 2.4 machines. I use it to 
> differentiate between primary provider/secondary provider, remote 
> administration on/off,... 
> I like it very much because I don't need to change the rules themselves in a 
> live production environment anymore and can therefore make my scripts much 
> more rule-independant.
> 
> Now I was playing around a bit with 2.6 and found the following comment from 
> you in cvs: "made it 2.4.x only, since I don't like it anyway."

This comment is meant as:

"Since nobody provided us with a 2.6.x port yet, and I have very limited
time for such porting, and I personnaly dislike the condition match
anyway, I marked it as 2.4.x only - since the 2.4.x patch doesn't work
for 2.6.x"

> What do you dislike? Is it the idea or the implementation? Do you know of any 
> bugs or possible problems in the code - especially with 2.6?

The idea of having /proc files control how the ruleset behaves.  This is
an ugly kludge for our less-than-optimal ruleset change performance.
Apart from that I cannot really see why this has to be solved in the
kernel and not by some userspace daemon that updates the ruleset
whenever a change is needed.

> Kind regards,
> Gerd

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: condition and 2.6

[Willy Tarreau]

On Sun, Feb 29, 2004 at 12:07:11PM +0100, Harald Welte wrote:
 
> > What do you dislike? Is it the idea or the implementation? Do you know of any 
> > bugs or possible problems in the code - especially with 2.6?
> 
> The idea of having /proc files control how the ruleset behaves.  This is
> an ugly kludge for our less-than-optimal ruleset change performance.
> Apart from that I cannot really see why this has to be solved in the
> kernel and not by some userspace daemon that updates the ruleset
> whenever a change is needed.

I was planning to try to use condition in a HA environment to temporarily
disable some rules during a fail-over, or for maintenance operations (eg:
disable health-checks but let application traffic go through for soft-stop).
I think that condition offers much more atomicity than a ruleset update, and
there's no risk of multiple loads of the same rule.

Anyway, I agree that for permanent changes, an update of the ruleset should
be preferred.

Regards,
Willy

Re: condition and 2.6

[Gerd v. Egidy]

> This comment is meant as:
>
> "Since nobody provided us with a 2.6.x port yet, and I have very limited
> time for such porting, and I personnaly dislike the condition match
> anyway, I marked it as 2.4.x only - since the 2.4.x patch doesn't work
> for 2.6.x"

Thank you for the clarification.

> > What do you dislike? Is it the idea or the implementation? Do you know of
> > any bugs or possible problems in the code - especially with 2.6?
>
> The idea of having /proc files control how the ruleset behaves.  This is
> an ugly kludge for our less-than-optimal ruleset change performance.
> Apart from that I cannot really see why this has to be solved in the
> kernel and not by some userspace daemon that updates the ruleset
> whenever a change is needed.

I don't mind that much about ruleset change speed. The different conditions 
for my firewall are changed by different scripts and I can't make sure that 
only one is running at a time. So I fear a race like this:

Program 1: iptc_init
Program 2: iptc_init
Program 1: modify rule A
Program 2: modify rule B
Program 1: iptc_commit
Program 2: iptc_commit

As far as I understand the libiptc code, the result will be that the changes 
done by program 1 will be lost. Is that correct or have I misunderstood the 
code?

The condition module offers a lot more atomicity and I can be sure that two 
scripts don't interfere with each other.

Kind regards,

Gerd

Re: condition and 2.6

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On Sun, Feb 29, 2004 at 03:28:01PM +0100, Gerd v. Egidy wrote:
> > This comment is meant as:
> >
> > "Since nobody provided us with a 2.6.x port yet, and I have very limited
> > time for such porting, and I personnaly dislike the condition match
> > anyway, I marked it as 2.4.x only - since the 2.4.x patch doesn't work
> > for 2.6.x"
> 
> Thank you for the clarification.
> 
> > > What do you dislike? Is it the idea or the implementation? Do you know of
> > > any bugs or possible problems in the code - especially with 2.6?
> >
> > The idea of having /proc files control how the ruleset behaves.  This is
> > an ugly kludge for our less-than-optimal ruleset change performance.
> > Apart from that I cannot really see why this has to be solved in the
> > kernel and not by some userspace daemon that updates the ruleset
> > whenever a change is needed.
> 
> I don't mind that much about ruleset change speed. The different conditions 
> for my firewall are changed by different scripts and I can't make sure that 
> only one is running at a time. So I fear a race like this:

Sorry, but I have a different view on this.  Problems that can be solved
in userspace (like mutual exclusion of certain scripts running at the
same time) should be implemented in userspace, rather than pushing
kludges into the kernel.

> As far as I understand the libiptc code, the result will be that the changes 
> done by program 1 will be lost. Is that correct or have I misunderstood the 
> code?

No, this is true.

> The condition module offers a lot more atomicity and I can be sure that two 
> scripts don't interfere with each other.

While I understand this application, I doubt that this rectifies the
race-prone uglyness of something like ipt_condition.

Why don't you just use a lock file in all your scripts?  Create the lock
file before you access iptables, and remove it after it has been
accessed.  This kind of file-based locking works since good old UUCP
times.

> Kind regards,
> Gerd

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: condition and 2.6

[Gerd v. Egidy]

> > I don't mind that much about ruleset change speed. The different
> > conditions for my firewall are changed by different scripts and I can't
> > make sure that only one is running at a time. So I fear a race like this:
>
> Sorry, but I have a different view on this.  Problems that can be solved
> in userspace (like mutual exclusion of certain scripts running at the
> same time) should be implemented in userspace, rather than pushing
> kludges into the kernel.

That's right - or the kernel will get even more bloated than it already is.

> > As far as I understand the libiptc code, the result will be that the
> > changes done by program 1 will be lost. Is that correct or have I
> > misunderstood the code?
>
> No, this is true.
>
> > The condition module offers a lot more atomicity and I can be sure that
> > two scripts don't interfere with each other.
>
> While I understand this application, I doubt that this rectifies the
> race-prone uglyness of something like ipt_condition.
>
> Why don't you just use a lock file in all your scripts?  Create the lock
> file before you access iptables, and remove it after it has been
> accessed.  This kind of file-based locking works since good old UUCP
> times.

Ok, judging from Willys comment I'm not the only one with problems / worries 
like this. The problem concerns not only my scripts but all users of libiptc 
(neglecting programs that directly use the kernel interface). So why not fix 
it there?

I think of a lockfile (e.g. /var/run/libiptc.pid) which is created by the 
library in iptc_init and removed in iptc_commit. This way all programs using 
libiptc become safe at once.

Do you like this idea?

Kind regards,

Gerd

Re: condition and 2.6

[Henrik Nordstrom]

On Sun, 29 Feb 2004, Gerd v. Egidy wrote:

> I think of a lockfile (e.g. /var/run/libiptc.pid) which is created by the 
> library in iptc_init and removed in iptc_commit. This way all programs using 
> libiptc become safe at once.

If this is done it should be optional.

iptables is used in very many applications, and not in all cases is there 
obvious plases to place lock files.

Regards
Henrik

Re: condition and 2.6

[Philip Craig]

Gerd v. Egidy wrote:
> I think of a lockfile (e.g. /var/run/libiptc.pid) which is created by the 
> library in iptc_init and removed in iptc_commit. This way all programs using 
> libiptc become safe at once.

This is not good enough, since iptc_init and iptc_commit are per table.

You could fix that by adding iptc_lock and iptc_unlock functions to libiptc.
This would work for iptables-save/restore, but it will still not help if
you are using multiple iptables commands to modify your rules.

The lock operations really need to be around your entire script, which
means you can't implement them in libiptc or the iptables commands.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com