Bug 1541077

Summary:	ipset hash:mac inet6 is not supported but accepted
Product:	Red Hat Enterprise Linux 8	Reporter:	Tomas Dolezal <todoleza>
Component:	firewalld	Assignee:	Vrinda <vpunj>
Status:	CLOSED ERRATA	QA Contact:	Jiri Peska <jpeska>
Severity:	low	Docs Contact:
Priority:	low
Version:	8.2	CC:	atragler, egarver, rkhan, todoleza
Target Milestone:	rc	Keywords:	Upstream
Target Release:	8.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	firewalld-0.8.2-2.el8	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-04 01:39:57 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 2018-02-01 16:07:16 UTC

Description of problem:
hash:mac does not allow family parameter.
ipset(8):This parameter is valid for the create command of all hash type sets except for hash:mac.
Firewalld permits it's configuration while it should not.

Version-Release number of selected component (if applicable):
firewalld-0.4.4.4-14.el7.noarch
ipset-6.29-1.el7.x86_64
kernel-4.14.0-29.el7a.x86_64

How reproducible:
always

Steps to Reproduce:
firewall-cmd --permanent --new-ipset hashmac --type hash:mac
success
firewall-cmd --permanent --new-ipset hashmacv6 --type hash:mac --family inet6
success

Actual results:
both ipsets are defined, but inet6 is not supported in ipset/(kernel?)
2018-02-01 11:04:52 ERROR: Failed to load ipset file '/etc/firewalld/ipsets/hashmacv6.xml': INVALID_OPTION: Unsupported option 'family' for type 'hash:mac'

Expected results:
failure on invalid family specification for hash:mac ipset type

Additional info:

Comment 1 Eric Garver 2018-02-01 16:18:32 UTC

The error is correct, but firewalld isn't propagating the error to firewall-cmd. The error can be seen in the firewalld logs though.

Comment 2 Tomas Dolezal 2018-02-01 17:21:15 UTC

the issue is not the (hidden) error, which is asynchronous to the --permanent+new, but the ability to create a configuration which is inevitably broken, successfully.

Unlike in firewall-offline-cmd, there's runtime which should be able to assess the configuration from environmental/other point of view.

there can be cases in which the assessment might not be possible, but not in this one. For others e.g. kernel refusing to accept a rule due to unknown constraints.

Comment 3 Eric Garver 2018-04-05 19:00:03 UTC

Currently firewalld only checks "ipset --help" output to guess if an ipset type is supported. This should be improved by attempting to create an ipset to verify the kernel actually supports the type.

See class ipset, method supported_types().

Comment 4 Eric Garver 2018-06-06 15:58:25 UTC

--family does not make sense with hash:mac. We should be able to deny this pretty early, long before it it's accepted to the configuration file.

Comment 6 Eric Garver 2020-05-07 17:25:03 UTC

This is a minor issue and there are no plans to fix this in RHEL-7. Moving to RHEL-8.

Comment 8 Vrinda 2020-06-30 18:09:00 UTC

Upstream:
dddba7b9c276 ("fix(cli): add ipset type hash:mac is incompatible with the family parameter")

Comment 14 errata-xmlrpc 2020-11-04 01:39:57 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 (firewalld bug fix and enhancement update), 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/RHBA-2020:4461