RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1442840 - dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Action org.fedoraproject.FirewallD1.config.info is not registered
Summary: dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Actio...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: polkit
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Polkit Maintainers
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
: 1436964 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-17 18:02 UTC by Scott Dodson
Modified: 2021-01-15 07:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-15 07:34:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Reproducer script (552 bytes, application/x-shellscript)
2017-04-21 10:38 UTC, Thomas Woerner 		no flags Details
Just hammer the PolkitBackndActionPool reload code (438 bytes, application/x-shellscript)
2017-04-26 20:24 UTC, Miloslav Trmač 		no flags Details
View All

Description Scott Dodson 2017-04-17 18:02:02 UTC 
Description of problem:
OpenShift installs and uses firewalld to configure the firewall. If iptables-services were installed we disable that service, install firewalld, start it, pause 10 seconds, and then attempt to start adding firewall rules via ansible's firewalld module.

Occasionally, we get the following error as soon as we start adding rules.

"dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Action org.fedoraproject.FirewallD1.config.info is not registered"

The one time I was able to reproduce this on a host restarting polkit made the problem go away so we've added a task that restarts polkit and then polls for the action to exist by running

pkaction --action-id=org.fedoraproject.FirewallD1.config.info

However the issue persists.


Version-Release number of selected component (if applicable):
dbus.x86_64                   1:1.6.12-17.el7
dbus-python.x86_64            1.1.1-9.el7
firewalld.noarch              0.4.3.2-8.1.el7_3.2
polkit.x86_64                 0.112-11.el7_3

How reproducible:
infrequently

Steps to Reproduce:
1. on a host that had iptables services enabled
2. yum install firewalld
3. systemctl stop iptables ip6tables
4. sleep 10
5. systemctl start firewalld
6. sleep 10
7. systemctl restart polkit
8. pkaction --action-id=org.fedoraproject.FirewallD1.config.info

Actual results:
dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Action org.fedoraproject.FirewallD1.config.info is not registered

Expected results:
policy action id exists, able to add rules via dbus

Additional info:
Comment 2 Thomas Woerner 2017-04-21 10:32:50 UTC 
Finally I have been able to reproduce this. It is a polkit issue.
Comment 3 Thomas Woerner 2017-04-21 10:38:27 UTC 
Created attachment 1273300 [details]
Reproducer script

1) Install 7.3 server minimal
2) Uninstall firewalld: rpm -e $(rpm -qa "*firewall*")
3) Install iptables-services
4) Enable and start iptables services: systemctl enable iptables ip6tables; systemctl start iptables ip6tables
5) Download the firewalld packages: firewalld-0.4.3.2-8.1.el7_3.noarch.rpm, firewalld-filesystem-0.4.3.2-8.1.el7_3.noarch.rpm and python-firewall-0.4.3.2-8.1.el7_3.noarch.rpm
6) Start script where rpms are located

Most likely the reproducer can be reduced to only do the firewalld installation, start and deinstallation.
Comment 4 Thomas Woerner 2017-04-21 10:39:04 UTC 
Reassigning to polkit.
Comment 5 Brian J. Murrell 2017-04-21 11:41:46 UTC 
We are seeing this occasionally/intermittently also.  But we don't install/remove iptables-services.
Comment 6 Brian J. Murrell 2017-04-21 12:33:16 UTC 
And it appears to happen even when previous firewall-cmd invocations were successful without any stop/start between.

I will try to collect more data.
Comment 8 Miloslav Trmač 2017-04-26 20:24:51 UTC 
Created attachment 1274388 [details]
Just hammer the PolkitBackndActionPool reload code

Thomas, is this _consistently_ reproducible using the above script? A single run didn’t do it for me.

I _was_ able to reproduce a failure to look up using the attached script…

… but it is not _yet_ clear to me that with either of the reproducers this is a real bug and not just an ~inherent race condition: polkit uses a GFileMonitor watch to notice new files being installed, and to load them, but there is no practical mechanism for callers to wait until that happens (the caller would have to restart polkitd, which is undesirable because it loses state).

So, it is possible _in principle_ that with these reproducers we are only encountering a race condition (more likely with my reproducer than with yours, because the RPM one does so much more and gives polkitd so much more opportunity to catch up).

OTOH this race condition is unlikely to apply to the original bug report, at least assuming the host / storage is mostly idle during the "sleep 10" (which neither of our reproducers has).

Still investigating…
Comment 17 Miloslav Trmač 2017-05-10 15:16:07 UTC 
For reference, I have filed bug 1449754 to modify firewalld packaging so that it doesn’t configure duplicate polkit action IDs.
Comment 20 Scott Dodson 2017-06-02 19:45:32 UTC 
*** Bug 1436964 has been marked as a duplicate of this bug. ***
Comment 21 Sally 2017-08-07 06:13:39 UTC 
I am using Fedora 26, I have I think the same issue here.

Firstly firewalld service didn't work, it asked for "cockpit" after I installed it, the firewalld service it looks working, but when I try to do anything with it, like

sudo firewall-cmd --list-all

I get an error, which says:

ERROR:dbus.proxies:Introspect error on :1.84:/org/fedoraproject/FirewallD1: dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Action org.fedoraproject.FirewallD1.info is not registered
Error: Action org.fedoraproject.FirewallD1.info is not registered
Comment 22 Miloslav Trmač 2017-08-22 15:23:27 UTC 
Jalal, please file a separate bug against Fedora; a RHEL fix is not going to change Fedora.  Besides, Fedora is already using polkit-0.113, which contains the fix being considered in this report.
Comment 23 Sally 2018-03-16 14:06:02 UTC 
Miloslav, Okay, I will, thank you.
By the way with polkit-0.113-15 the issue still there with Fedora
Comment 25 Joel 2018-12-25 08:22:46 UTC 
I am getting this after upgrading from Fedora 27 to Fedora 29.

[root@server ~]# firewall-cmd --zone=trusted --list-all
Error: Action org.fedoraproject.FirewallD1.config.info is not registered
Comment 27 RHEL Program Management 2021-01-15 07:34:08 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.