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


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 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.