Bug 1673609

Summary: iptables-save produces error if specified table is uninitialized
Product: Red Hat Enterprise Linux 8 Reporter: Tomas Dolezal <todoleza>
Component: iptablesAssignee: Phil Sutter <psutter>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: medium Docs Contact:
Priority: high    
Version: 8.1CC: chjones, iptables-maint-list, psutter, skaplons, tbowling, todoleza, toneata
Target Milestone: rcKeywords: Regression, ZStream
Target Release: 8.1Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: iptables-1.8.2-10.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1716819 (view as bug list) Environment:
Last Closed: 2019-11-05 22:17:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1682316    
Bug Blocks: 1716819    

Description Tomas Dolezal 2019-02-07 15:40:10 UTC
Description of problem:
ip(6)tables-save (nf_tables version) reports error for uninitialized table instead of empty/valid output if the table is not present in nf_tables.
The error is reported on standard output instead of standard error one.
If not specific table is queried via --table, the tool exits correctly without any messages and with 0 exit code.

On the contrary, iptables binary initializes queried tables in background when in --list mode thus always producing at least default output.

Version-Release number of selected component (if applicable):
iptables-1.8.2-5.el8.x86_64

How reproducible:
always

Steps to Reproduce:
ip6tables-save; echo EC=$?
EC=0
ip6tables-save -t raw 2> >(sed 's/^/err: /') > >(sed 's/^/out: /'); echo EC=$?
out: Table `raw' does not exist
EC=1
ip6tables-save -t foo 2> >(sed 's/^/err: /') > >(sed 's/^/out: /'); echo EC=$?
out: Table `foo' does not exist
EC=1
ip6tables -t raw -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

ip6tables-save -t raw 2> >(sed 's/^/err: /') > >(sed 's/^/out: /'); echo EC=$?
std: # Generated by xtables-save v1.8.2 on Thu Feb  7 10:35:27 2019
std: *raw
std: :PREROUTING ACCEPT [0:0]
std: :OUTPUT ACCEPT [0:0]
std: COMMIT
std: # Completed on Thu Feb  7 10:35:27 2019
EC=0

Actual results:
error is produced

Expected results:
ip(6)tables -t <valid_name> shows valid output/behaves the same as old iptables.
if stdout is used, the error should be after '#' which is ignored by '-restore' variant of command.

use of invalid table name is indistinguishable from valid name if the valid name is not present in nft ruleset

Additional info:

Comment 1 Phil Sutter 2019-02-07 21:18:46 UTC
Fix submitted upstream: https://marc.info/?l=netfilter-devel&m=154957400421907&w=2

Given that specifying a table to iptables-save is rather a corner-case and if used usually a non-empty ruleset exists, I guess this is safe to delay for RHEL8.1.

Comment 2 Phil Sutter 2019-02-08 16:33:58 UTC
Upstream commit to backport:

commit 2478b6cbb8112f940cec61ec1e62a598472d33d0
Author: Phil Sutter <phil>
Date:   Thu Feb 7 22:13:31 2019 +0100

    xtables-save: Fix table not found error message
    
    First of all, this error message should not appear on stdout, otherwise
    it may end in dump files. Next, with completely empty ruleset, even
    valid table names cause errors. To avoid this, continue operation if the
    not found table is a builtin one.
    
    Signed-off-by: Phil Sutter <phil>
    Signed-off-by: Florian Westphal <fw>

Comment 8 Phil Sutter 2019-03-11 14:44:30 UTC
When discussing this issue with Sushil, we decided to rather delay for 8.1 and go with z-stream fix if required. Looking at bug 1685705 again, the comment pointing out a workaround for 8.0 was posted after the request to resolve this ticket in 8.0. Consequently the ticket was closed, which to me indicates that mentioned workaround is sufficient for them.

Comment 21 errata-xmlrpc 2019-11-05 22:17:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3573