| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Simple test to make sure iptables-restore does not touch tables it is
not supposed to.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3dc433b55bbfa ("xtables-restore: Fix --table parameter check")
installed an error check which evaluated true in all cases as all
callers of do_command callbacks pass a pointer to a table name already.
Attached test case passed as it tested error condition only.
Fix the whole mess by introducing a boolean to indicate whether a table
parameter was seen already. Extend the test case to cover positive as
well as negative behaviour and to test ebtables-restore and
ip6tables-restore as well. Also add the required checking code to the
latter since the original commit missed it.
Fixes: 3dc433b55bbfa ("xtables-restore: Fix --table parameter check")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Xtables-restore tries to reject rule commands in input which contain a
--table parameter (since it is adding this itself based on the previous
table line). The manual check was not perfect though as it caught any
parameter starting with a dash and containing a 't' somewhere, even in
rule comments:
| *filter
| -A FORWARD -m comment --comment "- allow this one" -j ACCEPT
| COMMIT
Instead of error-prone manual checking, go a much simpler route: All
do_command callbacks are passed a boolean indicating they're called from
*tables-restore. React upon this when handling a table parameter and
error out if it's not the first one.
Fixes: f8e5ebc5986bf ("iptables: Fix crash on malformed iptables-restore")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The same piece of code appears three times, introduce a function to take
care of tokenizing and error reporting.
Pass buffer pointer via reference so it can be updated to point to after
the counters (if found).
While being at it, drop pointless casting when passing pcnt/bcnt to
add_argv().
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another corner-case found when extending restore ordering test: If a
delete command in a dump referenced a rule added earlier within the same
dump, kernel would reject the resulting NFT_MSG_DELRULE command.
Catch this by assigning the rule to delete a RULE_ID value if it doesn't
have a handle yet. Since __nft_rule_del() does not duplicate the
nftnl_rule object when creating the NFT_COMPAT_RULE_DELETE command, this
RULE_ID value is added to both NEWRULE and DELRULE commands - exactly
what is needed to establish the reference.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
| |
This test tended to cause quite excessive load on my system, sometimes
taking longer than all other tests combined. Even with the reduced
numbers, it still fails reliably after reverting commit 58d7de0181f61
("xtables: handle concurrent ruleset modifications").
Fixes: 4000b4cf2ea38 ("tests: add test script for race-free restore")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2: moved examples to testcase files
Legacy implementation of iptables-restore / ip6tables-restore allowed
to insert a -4 or -6 option at start of a rule line to ignore it if not
matching the command's protocol. This allowed to mix specific ipv4 and
ipv6 rules in a single file, as still described in iptables 1.8.3's man
page in options -4 and -6. The implementation over nftables doesn't behave
correctly in this case: iptables-nft-restore accepts both -4 or -6 lines
and ip6tables-nft-restore throws an error on -4.
There's a distribution bug report mentioning this problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925343
Restore the legacy behaviour:
- let do_parse() return and thus not add a command in those restore
special cases
- let do_commandx() ignore CMD_NONE instead of bailing out
I didn't attempt to fix all minor anomalies, but just to fix the
regression. For example in the line below, iptables should throw an error
instead of accepting -6 and then adding it as ipv4:
% iptables-nft -6 -A INPUT -p tcp -j ACCEPT
Signed-off-by: Adel Belhouane <bugs.a.b@free.fr>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two issues fixed:
* XTABLES_LIBDIR was set wrong (CWD is not topdir but tests/). Drop the
export altogether, the testscript does this already.
* $LINES is a variable set by bash, so initial dump sanity check failed
all the time complaining about a spurious initial dump line count. Use
$LINES1 instead.
Fixes: 4000b4cf2ea38 ("tests: add test script for race-free restore")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
xtables-nft-restore ignores -w, check that we don't add
duplicate rules when parallel restores happen.
With a slightly older iptables-nft version this ususally fails with:
I: [EXECUTING] iptables/tests/shell/testcases/ipt-restore/0004-restore-race_0
iptables-restore v1.8.2 (nf_tables):
line 5: CHAIN_USER_ADD failed (File exists): chain UC-0
line 6: CHAIN_USER_ADD failed (File exists): chain UC-1
W: [FAILED] ipt-restore/0004-restore-race_0: expected 0 but got 4
or
I: [EXECUTING] iptables/tests/shell/testcases/ipt-restore/0004-restore-race_0
iptables-restore v1.8.2 (nf_tables):
line 1: TABLE_FLUSH failed (No such file or directory): table filter
or
/tmp/tmp.SItN4URxxF /tmp/tmp.P1y4LIxhTl differ: byte 7159, line 137
As the legacy version should not have such race (due to nature
of full-table-replace), only do one iteration for legacy case.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iptables-restore allows to insert rules at a certain position which is
problematic for iptables-nft to realize since rule position is not
determined by number but handle of previous or following rule and in
case the rules surrounding the new one are new as well, they don't have
a handle to refer to yet.
Fix this by making use of NFTNL_RULE_POSITION_ID attribute: When
inserting before a rule which does not have a handle, refer to it using
its NFTNL_RULE_ID value. If the latter doesn't exist either, assign a
new one to it.
The last used rule ID value is tracked in a new field of struct
nft_handle which is incremented before each use.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Passing --wait option to iptables-nft-restore led to program abort
because the flag parameter was not skipped. Mimick iptables-restore
behaviour when encountering --wait or --wait-interval options (but still
ignore the parameter).
Fixes: b9d7b49d84bc2 ("xtables-compat: restore: sync options with iptables-restore")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
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
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
This will release the lock as soon as it's decided the current table won't be
used.
Signed-off-by: Joel Goguen <contact+netfilter@jgoguen.ca>
Signed-off-by: Florian Westphal <fw@strlen.de>
|