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 1436770 - NetworkManager service restart is required after FirewallD package installation to get active zone
Summary: NetworkManager service restart is required after FirewallD package installati...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-28 15:36 UTC by Lev Veyde
Modified: 2017-08-01 09:24 UTC (History)
12 users (show)

Fixed In Version: NetworkManager-1.8.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1444471 (view as bug list)
Environment:
Last Closed: 2017-08-01 09:24:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 0 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 12:40:28 UTC

Description Lev Veyde 2017-03-28 15:36:41 UTC 
Description of problem:
NetworkManager service restart is required after installation of FirewallD, in order to get the currently active zone.

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

How reproducible:
firewalld-0.4.3.2-8.1.el7_3.2

Steps to Reproduce:
1. Install RHEL
2. Configure network interfaces using legacy network scripts
3. Install FirewallD and start the service
4. run firewall-cmd --get-active-zone

Actual results:
It returns nothing

Expected results:
It should return a currently active zone, in my case it should be:

public
  interfaces: eth0 eth1

Additional info:

In order to fix the situation one needs to restart the NetWorkManager service following the installation of the Firewalld.

I tried to use the most updated version of the NetworkManager, kernel etc. and still getting the same result.

Interestingly enough it seems to work just fine on CentOS 7.3.

One can use Lago to easily build a reproducible working env., I used rhv-suite-4.1 and manually added latest RHEL 7.3 repo to test with the latest available packages.

Tested with:
NetworkManager-1.4.0-17.el7_3.x86_64 and NetworkManager-1.4.0-12.el7_3.x86_64
3.10.0-514.16.1.el7.x86_64 and 3.10.0-514.el7.x86_64

There are these messages in the /var/log/messages before the NetworkManager service is restarted after the FirewallD installation:

Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus-daemon: dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus-daemon: dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine NetworkManager[715]: <warn>  [1490713805.6565] firewall: [0x7f4b8368dcd0,change:"eth0"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -"))
Mar 28 11:10:05 lago-rhv-suite-4-1-engine NetworkManager[715]: <warn>  [1490713805.6568] firewall: [0x7f4b83643890,change:"eth1"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -"))
Comment 3 Thomas Woerner 2017-03-28 17:19:03 UTC 
The firewalld service is not started automatically after installation of the firewalld package. Because of this I do not understand why firewalld should restart NetworkManager in the firewalld installation process.

Restarting NetworkManager might result in a connection loss, therefore this is something that should not be done in my opinion.

Maybe the NetworkManager team could reveal why the access to the firewalld D-Bus interface is an issue here as the error is happening in NetworkManager.
Comment 4 Lev Veyde 2017-03-29 07:40:07 UTC 
(In reply to Thomas Woerner from comment #3)
> The firewalld service is not started automatically after installation of the
> firewalld package. Because of this I do not understand why firewalld should
> restart NetworkManager in the firewalld installation process.
> 
> Restarting NetworkManager might result in a connection loss, therefore this
> is something that should not be done in my opinion.
> 
> Maybe the NetworkManager team could reveal why the access to the firewalld
> D-Bus interface is an issue here as the error is happening in NetworkManager.

Hi Thomas,

The end result is that FirewallD (firewall-cmd) doesn't properly return information, and I'm not entirely sure for the reason. It would be nice if you could debug it from your side, to get more information, including more details where the request fails exactly, and so, if after that you're 100% certain that the issue is not in the FirewallD, but in the NetworkManager code, it would be easier for them to pinpoint the issue, and hopefully also get a faster resolution.
Comment 5 Thomas Haller 2017-04-20 16:19:38 UTC 
The problem is that NM does not react when firewalld is appearing later.

It's an NM bug. Reassigning.
Comment 6 Thomas Haller 2017-04-21 11:43:09 UTC 
Seems the problem is that dbus-daemon remembers that the NetworkManager process is not allowed to talk to firewalld. Later, when firewalld is installed, dbus-daemon still rejects the currently running NM process until it is restarted.

See also:

 - bug 1109513 (grep for "This introspection is prohibited by dbus-daemon")


Fixed upstream:


master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=cc1d409ba886e8e7c33f845790cfc700fcd2d854

nm-1-8: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ff5b7275a7584fcdabe4327f1a061c5610cf89dd
Comment 9 errata-xmlrpc 2017-08-01 09:24:38 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/RHSA-2017:2299
Note You need to log in before you can comment on or make changes to this bug.