Bug 1637675 - Attempting to remove a rich rule via FirewallClient python api results in dbus failure
Summary: Attempting to remove a rich rule via FirewallClient python api results in dbu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Garver
QA Contact: Jiri Peska
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks: 1723958
TreeView+ depends on / blocked
 
Reported: 2018-10-09 18:21 UTC by Adam Miller
Modified: 2020-03-31 20:01 UTC (History)
9 users (show)

Fixed In Version: firewalld-0.6.3-3.el7
Doc Type: Bug Fix
Doc Text:
.Deleting a `firewalld` rich rule with `forward-ports` works now as expected Previously, the `firewalld` service incorrectly handled the deletion of rules with the `forward-ports` setting. As a consequence, deleting a rich rule with `forward-ports` from the runtime configuration failed. This update fixes the problem. As a result, deleting a rich rule with `forward-ports` works as expected.
Clone Of:
Environment:
Last Closed: 2020-03-31 20:00:54 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github firewalld firewalld issues 482 'None' closed Error: remove-rich-rule fails to remove forward-port directive 2020-04-29 03:12:12 UTC
Red Hat Product Errata RHBA-2020:1109 None None None 2020-03-31 20:01:39 UTC

Description Adam Miller 2018-10-09 18:21:46 UTC
Description of problem:

>>> import firewall.config
>>> from firewall.client import FirewallClient
>>> fw = FirewallClient()
>>> fw.getDefaultZone()
'public'
>>> fw.removeRichRule('public', 'rule family=ipv4 forward-port port=80 protocol=tcp to-port=8080')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in removeRichRule
  File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 103, in _enable_proxy
    return func(*p, **k)
  File "<string>", line 2, in removeRichRule
  File "/usr/lib/python2.7/site-packages/firewall/client.py", line 53, in handle_exceptions
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/firewall/client.py", line 3017, in removeRichRule
    return dbus_to_python(self.fw_zone.removeRichRule(zone, rule))
  File "/usr/lib/python2.7/site-packages/slip/dbus/proxies.py", line 50, in __call__
    return dbus.proxies._ProxyMethod.__call__(self, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.fedoraproject.FirewallD1.Exception: %x format: a number is required, not NoneType

Version-Release number of selected component (if applicable):
python-firewall-0.4.4.4-15.el7_5.noarch

How reproducible:
Always

Comment 2 Eric Garver 2018-10-09 18:33:34 UTC
Adam, can you show the firewalld logs from /var/log/firewalld?

Comment 3 Adam Miller 2018-10-09 22:25:47 UTC
It appears that nothing is logged.


[root@ip-172-16-10-208 ~]# cat /var/log/firewalld
[root@ip-172-16-10-208 ~]# python
Python 2.7.5 (default, Apr 11 2018, 07:36:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from firewall.client import FirewallClient
>>> fw = FirewallClient()
>>> fw.getDefaultZone()
'public'
>>> fw.removeRichRule('public', 'rule family=ipv4 forward-port port=80 protocol=tcp to-port=8080')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in removeRichRule
  File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 103, in _enable_proxy
    return func(*p, **k)
  File "<string>", line 2, in removeRichRule
  File "/usr/lib/python2.7/site-packages/firewall/client.py", line 53, in handle_exceptions
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/firewall/client.py", line 3017, in removeRichRule
    return dbus_to_python(self.fw_zone.removeRichRule(zone, rule))
  File "/usr/lib/python2.7/site-packages/slip/dbus/proxies.py", line 50, in __call__
    return dbus.proxies._ProxyMethod.__call__(self, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.fedoraproject.FirewallD1.Exception: %x format: a number is required, not NoneType
>>> exit()
[root@ip-172-16-10-208 ~]# cat /var/log/firewalld
[root@ip-172-16-10-208 ~]#

Comment 4 Eric Garver 2018-10-10 20:06:31 UTC
Is firewalld running?

You can increase the log verbosity by add "--debug" in /etc/sysconfig/firewalld.

Comment 5 Adam Miller 2018-10-12 15:59:23 UTC
So, as of this morning I'm unable to reproduce the issue. I'm not sure what changed, but everything is working.

Comment 6 John Soros 2018-11-20 19:16:19 UTC
Strage, I am hitting this bug. It doesn't happen if I add --permanent before it, so I guess the solution for now is to remove the permanent rule and restart the firewall.

Comment 7 Eric Garver 2019-04-11 14:54:41 UTC
(In reply to John Soros from comment #6)
> Strage, I am hitting this bug. It doesn't happen if I add --permanent before
> it, so I guess the solution for now is to remove the permanent rule and
> restart the firewall.

Can you confirm that you're using a rich rule with forward ports?

Comment 8 John Soros 2019-04-11 16:49:47 UTC
Yes that is correct.

Comment 9 Eric Garver 2019-04-12 19:53:55 UTC
Upstream:

  4116829da430 ("test: add coverage for gh #482")
  362ebff80161 ("fix: rich rule forward-port deletion after reload")

Comment 18 errata-xmlrpc 2020-03-31 20:00:54 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/RHBA-2020:1109


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