UPSTREAM: iptables: insist that the lock is held.

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.

(cherry picked from iptables 80d8bfaac9e2430d710084a10ec78e68bd61e6ec)

Test: aosp_bullhead-eng builds
Change-Id: I1aec4eb2d9e3775806c93ccd6cf215af05e12f3c
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
6 files changed