[Bug 1394] New: "Bad argument `ACCEPT'" when iptables-restore (nft) parses stdin

[bugzilla-daemon at netfilter.org]

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

            Bug ID: 1394
           Summary: "Bad argument `ACCEPT'" when iptables-restore (nft)
                    parses stdin
           Product: iptables
           Version: unspecified
          Hardware: x86_64
               URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=9462
                    89
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables-restore
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: jamie at strandboge.com

In Debian, a user reported that ufw (a frontend to iptables) was not working:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946289

After investigating, this turned out to be an issue with iptables-nft-restore
(recall that in Debian there are both the nft and the legacy commands that
users may choose). Here is a simple reproducer on Debian with 1.8.4-1:

Create some simple policy:

$ cat /tmp/pol
*filter
# builtin chains
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

With 1.8.2-4 on buster:

$ cat /tmp/pol | sudo /usr/sbin/iptables-legacy-restore -n
$ cat /tmp/pol | sudo /usr/sbin/iptables-nft-restore -n
$

With 1.8.4-1 on sid:

$ cat /tmp/pol | sudo /usr/sbin/iptables-legacy-restore -n
$ cat /tmp/pol | sudo /usr/sbin/iptables-nft-restore -n
Bad argument `ACCEPT'
Error occurred at line: 4
Try `iptables-nft-restore -h' or 'iptables-nft-restore --help' for more
information.

but everything seems fine when parsing the file directly:

$ sudo /usr/sbin/iptables-legacy-restore /tmp/pol
$ sudo /usr/sbin/iptables-nft-restore /tmp/pol
$

The reporter in the bug claimed that downgrading to 1.8.3 allowed things to
work again, so it appears that this was introduced in 1.8.4.

I see that parsing behavior changed in
https://git.netfilter.org/iptables/commit/?h=v1.8.4&id=a7a6062f8ffe789703a6b4397c08dfb0c20a3009,
but I did not perform a bisect to determine it as the cause for the regression.

-- 
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/20200106/d94b993a/attachment.html>