| Summary: | Attempting to remove a rich rule via FirewallClient python api results in dbus failure | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Adam Miller <admiller> |
| Component: | firewalld | Assignee: | Eric Garver <egarver> |
| Status: | CLOSED ERRATA | QA Contact: | Jiri Peska <jpeska> |
| Severity: | medium | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
| Priority: | medium | ||
| Version: | 7.5 | CC: | admiller, egarver, jmaxwell, jpeska, pasik, rkhan, sbrivio, sorosj, todoleza |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-31 20:00:54 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1723958 | ||
|
Description
Adam Miller
2018-10-09 18:21:46 UTC
Adam, can you show the firewalld logs from /var/log/firewalld? 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 ~]# Is firewalld running? You can increase the log verbosity by add "--debug" in /etc/sysconfig/firewalld. So, as of this morning I'm unable to reproduce the issue. I'm not sure what changed, but everything is working. 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. (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? Yes that is correct. Upstream:
4116829da430 ("test: add coverage for gh #482")
362ebff80161 ("fix: rich rule forward-port deletion after reload")
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 |