[Bug 1348] New: v1.8.2 iptables-nft-restore incorrectly handles multiple replace commands

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1348

            Bug ID: 1348
           Summary: v1.8.2 iptables-nft-restore incorrectly handles
                    multiple replace commands
           Product: iptables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables-restore
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: shaun at tigera.io

Our project uses iptables-nft-restore in noflush mode as a way to run lots of
iptables commands quickly.  We've found that, in nft mode, if we use -R to
replace rules, then the rule that gets replaced is only correct for the first
-R.  Subsequent replaces seem to replace the same rule again:

$ iptables-save
# Generated by xtables-save v1.8.2 on Thu Jul  4 13:13:27 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:test - [0:0]
-A test -m comment --comment 1 
-A test -m comment --comment 2 
COMMIT

$ iptables-restore --noflush
*filter
-R test 1 -m comment --comment 1a
-R test 2 -m comment --comment 2a
COMMIT

With legacy mode, I get this, as expected, both rules are replaced:

# Generated by iptables-save v1.8.2 on Thu Jul  4 13:19:00 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:test - [0:0]
-A test -m comment --comment 1a
-A test -m comment --comment 2a
COMMIT
# Completed on Thu Jul  4 13:19:00 2019

But with nft mode, we get

$ iptables-save
# Generated by xtables-save v1.8.2 on Thu Jul  4 13:14:09 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:test - [0:0]
-A test -m comment --comment 2a 
-A test -m comment --comment 2 
COMMIT

The first rule has been doubly replaced.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190704/e800f0c6/attachment.html>