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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
