Bug 1653562
| Summary: | [RHEL8] iptables v1.8.1 (nf_tables): realm: could not map name to integer | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | yiche <yiche> |
| Component: | iptables | Assignee: | Phil Sutter <psutter> |
| Status: | CLOSED ERRATA | QA Contact: | Jiri Peska <jpeska> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | iptables-maint-list, jpeska, psutter, todoleza, yiche |
| Target Milestone: | rc | Keywords: | ManPageChange |
| Target Release: | 8.1 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | iptables-1.8.2-10.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 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: | |||
|
Description
yiche
2018-11-27 06:37:21 UTC
Hi Yiche, (In reply to yiche from comment #0) > Description of problem: > iptables v1.8.1 (nf_tables): realm: could not map name -0x1/0xffff to an > integer value for option "--realm". > > Version-Release number of selected component (if applicable): > iptables-1.8.1-2.el8.x86_64 > kernel-4.18.0-40.el8.x86_64 > > > How reproducible: > always > > Steps to Reproduce: > #iptables -A INPUT -i lo -p tcp -m realm --realm -0x1/0xffff -j DROP > iptables v1.8.1 (nf_tables): realm: could not map name -0x1/0xffff to an > integer value for option "--realm". Is this a typo or do you really try to match on a negative realm value? Looking at the code, this seems not to be supported. Cheers, Phil But this behavior is different from RHEL7:
iptables -A INPUT -i lo -p tcp -m realm --realm -0x1/0xffff -j DROP
iptables -A INPUT -i lo -p tcp -m realm --realm 0x1/0xffff -j DROP
# iptables -nvL
Chain INPUT (policy ACCEPT 28 packets, 1960 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- lo * 0.0.0.0/0 0.0.0.0/0 realm 0xffffffff/0xffff
0 0 DROP tcp -- lo * 0.0.0.0/0 0.0.0.0/0 realm 0x1/0xffff
I think we should follow the behavior.Or give a explain in document.
Hi Yiche, (In reply to yiche from comment #2) > But this behavior is different from RHEL7: > iptables -A INPUT -i lo -p tcp -m realm --realm -0x1/0xffff -j DROP > iptables -A INPUT -i lo -p tcp -m realm --realm 0x1/0xffff -j DROP > # iptables -nvL > Chain INPUT (policy ACCEPT 28 packets, 1960 bytes) > pkts bytes target prot opt in out source > destination > 0 0 DROP tcp -- lo * 0.0.0.0/0 > 0.0.0.0/0 realm 0xffffffff/0xffff > 0 0 DROP tcp -- lo * 0.0.0.0/0 > 0.0.0.0/0 realm 0x1/0xffff > I think we should follow the behavior.Or give a explain in document. It is actually a bug in older iptables shipped with RHEL7, the value should not be accepted. Recent iptables rejects the negative value both in legacy and nft variant, so this is intended behaviour. I sent an enhancement to realm match documentation upstream: https://marc.info/?l=netfilter-devel&m=154384516505389&w=2 Upstream commit to backport:
commit 290d76b443bf24999d9caacb3fdd027d6e7112a1
Author: Phil Sutter <phil>
Date: Mon Dec 3 14:52:28 2018 +0100
extensions: libipt_realm: Document allowed realm values
Older versions of iptables allowed for negative realm values by accident
(they would be cast to unsigned). While this was clearly a bug, document
the fixed behaviour.
Signed-off-by: Phil Sutter <phil>
Signed-off-by: Pablo Neira Ayuso <pablo>
I file a new bug for RHEL7: Bug 1657075 Hi Yiche, (In reply to yiche from comment #5) > I file a new bug for RHEL7: Bug 1657075 Thanks for that! Merely a documentation issue, therefore moving to 8.1. 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 |