Re: [PATCH] iptables: insist that the lock is held.

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, May 19, 2017 at 04:08:59PM +0900, Lorenzo Colitti wrote:
> Currently, iptables programs will exit with an error if the
> iptables lock cannot be acquired, but will silently continue if
> the lock cannot be opened at all. This can cause unexpected
> failures (with unhelpful error messages) in the presence of
> concurrent updates, which can be very difficult to find in a
> complex or multi-administrator system.
> 
> Instead, refuse to do anything if the lock cannot be acquired.
> The behaviour is not affected by command-line flags because:
> 
> 1. In order to reliably avoid concurrent modification, all
>    invocations of iptables commands must follow this behaviour.
> 2. Whether or not the lock can be opened is typically not
>    a run-time condition but is likely to be a configuration
>    error.
> 
> Existing systems that depended on things working mostly correctly
> even if there was no lock might be affected by this change.
> However, that is arguably a configuration error, and now that the
> iptables lock is configurable, it is trivial to provide a lock
> file that is always accessible: if nothing else, the iptables
> binary itself can be used. The lock does not have to be writable,
> only readable.
> 
> Tested by configuring the system to use an xtables.lock file in
> a non-existent directory and observing that all commands failed.

Applied, thanks Lorenzo.