Re: condition and 2.6

["Gerd v. Egidy" <lists@egidy.de>]

> > 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