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

[Ben Hutchings]

Control: tag -1 upstream

On Sat, 27 Feb 2016 21:06:57 +1030 Ron <ron at debian.org> wrote:
> Package: iptables
> Version: 1.4.21-2+b1
> Severity: important
> 
> Hi,
> 
> So, somewhere between Wheezy and Jessie, iptables starting using locking
> 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.
> 
> 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 ...

This sounds hard to believe as the kernel should remove the lock
synchronously as the process exits.  If it doesn't then I suppose
there's a kernel bug here as well. :-/

However, it's entirely possible that multiple processes may run
iptables in parallel at boot time; there's an example given here:
https://utcc.utoronto.ca/~cks/space/blog/linux/IptablesUseWOption

[...] 
> I'm inclined to think -w should actually be the default,

I agree with this.

[...]
> But I do think this needs to be
> either far more widely advertised as an incompatible and dangerous
> change, or mitigated in some better way that doesn't make things
> which were working in Wheezy gain a new and subtle failure mode
> for Jessie and later releases.

A race condition already existed, and the new behaviour (exit with
error message) seems better than the previous behaviour (quiet
overwrite), not a regression in iptables.

However, the switch to systemd as default init system in jessie
presumably makes the race condition more likely, so that there *is* a
regression in Debian GNU/Linux.  That makes it more important to fix
the race properly, i.e. iptables should wait by default.  That also
means there needs to be a way to disable waiting, which would need to
be discussed upstream first.

Ben.

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding
stump
of a severed limb. - me, 29 June 1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-netfilter-devel/attachments/20160924/d9785c3c/attachment.sig>