Bug 1816300

Summary: chain name 'in' not considered a string
Product: Red Hat Enterprise Linux 8 Reporter: Tomas Dolezal <todoleza>
Component: nftablesAssignee: Phil Sutter <psutter>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.2CC: todoleza
Target Milestone: rcKeywords: Regression
Target Release: 8.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-26 20:10:04 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:

Description Tomas Dolezal 2020-03-23 18:42:34 UTC
Description of problem:
"in" is considered a keyword and thus prevented from being accepted as chain name. This behaviour changed since rhel-8.1.0.

Version-Release number of selected component (if applicable):
nftables-0.9.3-11.el8.x86_64
iptables-1.8.4-9.el8.x86_64

How reproducible:
always

Steps to Reproduce:
iptables -N in
nft list ruleset | tee rules.nft
nft flush ruleset
nft -f rules.nft

Actual results:
table ip filter {
	chain INPUT {
		type filter hook input priority filter; policy accept;
	}

	chain FORWARD {
		type filter hook forward priority filter; policy accept;
	}

	chain OUTPUT {
		type filter hook output priority filter; policy accept;
	}

	chain in {
	}
}
rules.nft:14:8-9: Error: syntax error, unexpected in, expecting string
	chain in {
	      ^^
rules.nft:16:1-1: Error: syntax error, unexpected '}'
}
^

Expected results:
successful rules load

Additional info:
double quotation marks cause another type of error:
Error: syntax error, unexpected quoted string, expecting string

Comment 1 Phil Sutter 2020-03-26 20:10:04 UTC
Yes, this is due to upstream commit 57c2b152c5f08 ("src: add ipsec (xfrm)
expression") which added new keywords "in" and "out".

Basically it's the same issue as reported in bug 1658716, so marking this one
as a duplicate.

*** This bug has been marked as a duplicate of bug 1658716 ***