[Pkg-netfilter-devel] Bug#816087: iptables is racy by default when used in scripts

[Arturo Borrero Gonzalez]

Hi Ron,

please find below some comments.

On Sat, 27 Feb 2016 21:06:57 +1030 Ron <ron at debian.org> wrote:
>
> So, somewhere between Wheezy and Jessie, iptables starting using locking

Have you tested iptables 1.6.0? (currently in stretch testing).

> to avoid racy updates to the kernel state, which means the command line
> tool will now sometimes fail with:
>
>  "Another app is currently holding the xtables lock."
>
> Which is good, except that means the command line tool itself has now
> introduced race conditions which scripts calling it repeatedly can lose
> unless they explicitly pass the -w option to wait for the lock.
>

As far as I know, that was the idea.
If you need updates in a concurrent environment, you should use the -w
switch to wait for the lock.
I don't see any problem up to this point, don't you?

> The problem seems to be that iptables itself will return before the
> xtables lock has been released, so a script calling it multiple times
> is prone to fail somewhere in the middle of what it is doing ...
>

Could you please elaborate a bit more?

>From your report, I understand this sequence of events:

1) you run an iptables command (let's say iptables -A FORWARD -i whatever)
2) iptables then adquires the xtables lock
3) iptables builds the new ruleset and send it to the kernel
4) iptables returns
5) iptables releases the xtables lock??

How is that possible?? I'm sure I'm missing something.

>
> I'm inclined to think -w should actually be the default, though I
> understand that could have the undesirable side effect of deadlocking
> in some pathological use cases ...  but at the very least it seems
> like the iptables command shouldn't return to the caller until the
> lock is really released.  Which would least make it safe(r) for an
> existing single threaded script to call it repeatedly without needing
> modification (though it could still get nuked by some other caller
> running a command that takes the xtables lock) ...
>

Before reporting this issue to upstream I would like to be sure I
understand the problem you are describing.

thanks, best regards.