Account registration has been disabled due to spammer attacks, please send an email to bugzilla-account@netfilter.org to request your account, please also describe the bug you would like to report as a way to prove you are not a spammer :-)
First Last Prev Next    This bug is not in your last search results.
Bug 1271 - iptables-restore may double-lock when using --table
iptables-restore may double-lock when using --table
Status: RESOLVED FIXED
Product: iptables
Classification: Unclassified
Component: iptables-restore
1.6.x
x86_64 Fedora
: P5 minor
Assigned To: netfilter buglog mailinglist
Depends on:
Blocks:
  Show dependency tree / graph
 
Reported: 2018-07-13 19:47 CEST by contact+netfilter
Modified: 2018-07-27 22:08 CEST (History)
0 users

See Also:

Attachments
Path to free the lock when skipping a table (4.97 KB, patch)
2018-07-13 19:47 CEST, contact+netfilter 		Details
Dump file used for testing iptables-restore (720 bytes, text/plain)
2018-07-13 19:48 CEST, contact+netfilter 		Details
Dump file used for testing ip6tables-restore (700 bytes, text/plain)
2018-07-13 19:49 CEST, contact+netfilter 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description contact+netfilter 2018-07-13 19:47:10 CEST 
Created attachment 541 [details]
Path to free the lock when skipping a table

Currently, when running `iptables-restore --table=X`, where `X` is not the first
table in the rules dump, the restore will fail when parsing the second table:

- a lock is acquird when parsing the first table name
- the table name does not match the parameter to `--table` so processing
continues until the next table
- when processing the next table a lock is acquired, which fails because a lock
is already held

This will release the lock as soon as it's decided the current table won't be
used.

With existing code:

    # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination

    # iptables-restore <iptables.dump
    Another app is currently holding the xtables lock. Perhaps you want to use
the -w option?

    # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination

With the change from the attached patch:
    # iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination

    # iptables-restore <iptables.dump

    # iptables -L
    Chain INPUT (policy DROP)
    target     prot opt source               destination
    ACCEPT     all  --  anywhere             anywhere
    ACCEPT     all  --  anywhere             anywhere             state
RELATED,ESTABLISHED
    ACCEPT     icmp --  anywhere             anywhere

    Chain FORWARD (policy DROP)
    target     prot opt source               destination

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    REJECT     tcp  --  anywhere             anywhere             tcp
dpt:netbios-ns reject-with icmp-port-unreachable
    REJECT     udp  --  anywhere             anywhere             udp
dpt:netbios-ns reject-with icmp-port-unreachable

And the test suite:
    # ./iptables/tests/shell/run-tests.sh

    I: [OK]          ././iptables/tests/shell/testcases/chain/0001duplicate_1
    I: [OK]          ././iptables/tests/shell/testcases/chain/0002newchain_0
    I: [OK]          ././iptables/tests/shell/testcases/chain/0003rename_1
    I: [OK]          ././iptables/tests/shell/testcases/ebtables/0001-ebtables-
basic_0
    I: [OK]          ././iptables/tests/shell/testcases/firewalld-restore/0001-
firewalld_0
    I: [OK]          ././iptables/tests/shell/testcases/firewalld-restore/0002-
firewalld-restart_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-restore/0001load-
specific-table_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-save/0001load-
dumps_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-save/0002load-
fedora27-firewalld_0
    I: legacy results: [OK] 9 [FAILED] 0 [TOTAL] 9
    I: [OK]          ././iptables/tests/shell/testcases/chain/0001duplicate_1
    I: [OK]          ././iptables/tests/shell/testcases/chain/0002newchain_0
    I: [OK]          ././iptables/tests/shell/testcases/chain/0003rename_1
    I: [OK]          ././iptables/tests/shell/testcases/ebtables/0001-ebtables-
basic_0
    I: [OK]          ././iptables/tests/shell/testcases/firewalld-restore/0001-
firewalld_0
    I: [OK]          ././iptables/tests/shell/testcases/firewalld-restore/0002-
firewalld-restart_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-restore/0001load-
specific-table_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-save/0001load-
dumps_0
    I: [OK]          ././iptables/tests/shell/testcases/ipt-save/0002load-
fedora27-firewalld_0
    I: nft results: [OK] 9 [FAILED] 0 [TOTAL] 9
    I: combined results: [OK] 18 [FAILED] 0 [TOTAL] 18
Comment 1 contact+netfilter 2018-07-13 19:48:12 CEST 
Created attachment 542 [details]
Dump file used for testing iptables-restore
Comment 2 contact+netfilter 2018-07-13 19:49:03 CEST 
Created attachment 543 [details]
Dump file used for testing ip6tables-restore
Comment 3 contact+netfilter 2018-07-27 22:08:15 CEST 
Merged according to https://marc.info/?l=netfilter-devel&m=153261050527770
First Last Prev Next    This bug is not in your last search results.