Bug 1790948 - Deleting ipsets using firewall-cmd does not remove them from the underlying system
Summary: Deleting ipsets using firewall-cmd does not remove them from the underlying s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: firewalld
Version: 8.4
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: 8.0
Assignee: Eric Garver
QA Contact: Jiri Peska
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks: 1807630
TreeView+ depends on / blocked
 
Reported: 2020-01-14 15:11 UTC by mcolombo
Modified: 2021-08-30 15:39 UTC (History)
5 users (show)

Fixed In Version: firewalld-0.8.2-1.el8
Doc Type: Bug Fix
Doc Text:
.The `firewalld` service now removes `ipsets` when the service stops Previously, stopping the `firewalld` service did not remove `ipsets`. This update fixes the problem. As a result, `ipsets` are no longer left in the system after `firewalld` stops.
Clone Of:
Environment:
Last Closed: 2020-11-04 01:39:57 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github firewalld firewalld issues 330 0 None closed ipset not removed by firewalld 2020-11-27 05:25:19 UTC
Red Hat Bugzilla 1682913 0 medium CLOSED native ipsets are not cleaned up upon daemon exit 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 4734671 0 None None None 2020-03-30 03:57:57 UTC
Red Hat Product Errata RHBA-2020:4461 0 None None None 2020-11-04 01:40:21 UTC

Description mcolombo 2020-01-14 15:11:55 UTC
Description of problem:
Deleting ipsets using firewall-cmd does not remove ipset from the underlying system.

Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:

# firewall-cmd --permanent --new-ipset=test --type=hash:net --option=family=inet6
success
# firewall-cmd --permanent --ipset=test --add-entry=::1
success
# systemctl reload firewalld
# firewall-cmd --get-ipsets
test
# firewall-cmd --permanent --delete-ipset=test
success
# firewall-cmd --get-ipsets
test
# systemctl reload firewalld
# firewall-cmd --get-ipsets
# firewall-cmd --get-ipsets | wc -l
0
# ls /etc/firewalld/ipsets/
text.xml.old
# cat /etc/firewalld/ipsets/test.xml.old 
<?xml version="1.0" encoding="utf-8"?>
<ipset type="hash:net">
  <option name="family" value="inet6"/>
  <entry>::1</entry>
</ipset>
# firewall-cmd --reload
success
# ipset --list
Name: test
Type: hash:net
Revision: 6
Header: family inet6 hashsize 1024 maxelem 65536
Size in memory: 1272
References: 0
Number of entries: 1
Members:
::1


Actual results:
/etc/firewalld/ipsets/<ipset>.xml is removed, however the ipset is still present in "ipset --list"

Expected results:
/etc/firewalld/ipsets/<ipset.xml> to be removed and also no longer have ipset present in "ipset --list"

Additional info:
This behavior appears to be present in upstream along with RHEL 8 and RHEL 7. There appears to have been an upstream discussion about this behavior seen in the following conversation.

      https://github.com/firewalld/firewalld/issues/330

As firewalld has the ability to remove all rules from iptable/nftables and reapply all configured rules on a --reload. I feel the same behavior should apply to ipsets as well. I feel that the behavior is at least implied. I can understand that we can only make permanent changes to ipsets using the permanent flag, but I see no reason why we cannot flush all ipsets and reapply configured ipsets on a "--reload" to conform to the behavior that exists in relation to how firewalld interacts with iptables/nftables.

Comment 1 Eric Garver 2020-03-03 17:33:46 UTC
Upstream:

81d784f8c856 ("test: ipset: verify clean up on exit/reload")
f5ed30ce7175 ("fix: ipset: destroy runtime sets on reload/stop")

Comment 10 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


Note You need to log in before you can comment on or make changes to this bug.