On Thu, Apr 20, 2017 at 06:23:33PM +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 sounds to me like a wrong design decision was made when introducing this userspace lock. > This can cause unexpected failures (with unhelpful error messages) > in the presence of concurrent updates. > > This patch adds a compile-time option that causes iptables to > refuse to do anything if the lock cannot be acquired. It is a > compile-time option instead of a command-line flag 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. > > Tested by deleting xtables.lock and observing that all commands > failed if iptables was compiled with --enable-strict-locking, but > succeeded otherwise. > > By default, --enable-strict-locking is disabled for backwards > compatibility reasons. It can be enabled by default in a future > change if desired. I would like to skip this compile time switch, if the existing behaviour is broken, we should just fix it. What is the scenario that can indeed have an impact in terms of backward compatibility breakage? Does it really make sense to keep a buggy behaviour around? -- 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
