|author||Lorenzo Colitti <email@example.com>||2017-03-16 16:55:02 +0900|
|committer||Pablo Neira Ayuso <firstname.lastname@example.org>||2017-03-21 14:54:03 +0100|
iptables-restore: support acquiring the lock.
Currently, iptables-restore does not perform any locking, so it is not safe to use concurrently with iptables. This patch makes iptables-restore wait for the lock if -w was specified. Arguments to -w and -W are supported in the same was as they are in iptables. The lock is not acquired on startup. Instead, it is acquired when a new table handle is created (on encountering '*') and released when the table is committed (COMMIT). This makes it possible to keep long-running iptables-restore processes in the background (for example, reading commands from a pipe opened by a system management daemon) and simultaneously run iptables commands. If -w is not specified, then the command proceeds without taking the lock. Tested as follows: 1. Run iptables-restore -w, and check that iptables commands work with or without -w. 2. Type "*filter" into the iptables-restore input. Verify that a) iptables commands without -w fail with "another app is currently holding the xtables lock...". b) iptables commands with "-w 2" fail after 2 seconds. c) iptables commands with "-w" hang until "COMMIT" is typed into the iptables-restore window. 3. With the lock held by an ip6tables-restore process: strace -e flock /tmp/iptables/sbin/iptables-restore -w 1 -W 100000 shows 11 calls to flock and fails. 4. Run an iptables-restore with -w and one without -w, and check: a) Type "*filter" in the first and then the second, and the second exits with an error. b) Type "*filter" in the second and "*filter" "-S" "COMMIT" into the first. The rules are listed only when the first copy sees "COMMIT". Signed-off-by: Narayan Kamath <email@example.com> Signed-off-by: Lorenzo Colitti <firstname.lastname@example.org> Signed-off-by: Pablo Neira Ayuso <email@example.com>
Diffstat (limited to 'libxtables')
0 files changed, 0 insertions, 0 deletions