Bug 1616363 - Improve handling of externally managed device (external modifications by the user)
Summary: Improve handling of externally managed device (external modifications by the ...
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
: 1542978 (view as bug list)
Depends On: 1650221 1650228 1816202
Blocks: 1592684 1627876
TreeView+ depends on / blocked
Reported: 2018-08-15 17:45 UTC by Tomas Dolezal
Modified: 2021-01-08 07:34 UTC (History)
9 users (show)

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

Attachments (Terms of Use)

Description Tomas Dolezal 2018-08-15 17:45:02 UTC
Description of problem:
FirewallD dropped sync of zone assignment with NM for connections that are generated, like docker0. The connection has been changing on every boot which made setting persistent setting impossible.
As of now, it is possible to create a zone assignment in NM that is ignored by firewalld. Instead, user should be informed that this operation is not possible and zone assignment need to be done either on persistent connection or directly in firewalld

firewalld change tracked in bug 1592684 comment 9

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

How reproducible:

Steps to Reproduce:
>have a generated connection (start docker)
>make a firewalld zone assignment
firewall-cmd --change-interface docker0 --zone work
firewall-cmd --change-interface docker0 --zone work --permanent
>later, make zone assignment via NM
nmcli connection modify docker0 connection.zone internal

Actual results:
[root@172 ~]# firewall-cmd --get-active-zones
  interfaces: docker0
  interfaces: eth0
[root@172 ~]# nmcli con show docker0 | grep zone
connection.zone:                        --

[root@172 ~]# nmcli con show docker0 | grep zone
connection.zone:                        internal
[root@172 ~]# firewall-cmd --get-active-zones
  interfaces: docker0
  interfaces: eth0

Expected results:
zone maintains an unset state '--' in NM
error or alike message is presented if nmcli or nm-gui is used

Additional info:

Comment 2 Eric Garver 2018-08-15 17:56:24 UTC
Does it make sense to allow _any_ permanent configuration changes on a generated interface? IMO "generated" itself implies transient - so I wouldn't expect anything to persist.

Comment 3 Thomas Haller 2018-08-24 09:02:14 UTC
From NetworkManager's point of view, when a device is not explicitly configured to be unmanaged, and if NetworkManager has currently no profile active on that device, the device lingers in state "disconnected" or "unavailable".

The reason why there is no profile active, is because 
  - no suitable profile was configured
  - no suitable profile was ready to autoconnect
  - no suitable profile was manually activated by the user (nmcli connection up)

Anyway, so assume the device lingers in state "disconnected" or "unavailable", and NetworkManager isn't doing anything about it. If somebody else starts configuring IP addresses, NetworkManager generates an in-memory profile and pretends that the interface is up. It's supposed not to interfere with this interface at all, because clearly somebody else (docker!) handles it. I find this behaviour rather odd, but I guess, it makes some sense to express on the API that something on this device is happening.

This generated profile can be modified like any other regular profile.

  $ nmcli connection modify docker0 connection.zone internal

This may also mean, that the in-memory profile gets now persisted to disk. On top of that, when such a profile is modified, NetworkManager takes that as command to take over managing the device gracefully. For example, previously the generated profile might be generated with ipv4.method=auto, but NetworkManager would not actually start a DHCP client. It was pretend-only. But when taking over managing, NetworkManager would be expected to actually start doing DHCP on the device.

Ok, it gets more complicated. Usually, when you modify a regular profile which is currently active on a device, this modification does not take effect immediately. Not until `nmcli device reapply` or full reactivation of the profile.
So, with respect of "taking over managing the interface" one would expect that if you have an externally generated interface and you do

  $ nmcli connection modify "$PROFILE" ethernet.mtu 1400

then NetworkManager would persist the profile and start to fully manage the device. But it should not change the MTU right away because you only modified the profile.

However, there is an exception: when you modify "connection.zone" and "connection.metered" properties of a profile which is currently active, these two properties take effect immediately. So, one would expect that indeed the zone changes right away.

  $ nmcli connection modify docker0 connection.zone internal
  $ firewall-cmd --get-active-zones
    interfaces: docker0

Btw, the docker0 bridge is managed by docker. It simply makes no sense to tell NetworkManager to interfere with this interface and the user is advised to leave the generated NetworkManager profile alone. However, the bug report does make sense

I see three options what we can do:

 1) fix "take over fully managing the device" to properly behave according to 
    what I described. In particular w.r.t. the firewall zone.
 2) NetworkManager should prevent modifying such a profile via D-Bus. 
    Care must be taken, that the user also cannot drop a profile with the same
    UUID to disk and modify the generated profile via `nmcli connection reload`
 3) stop generating these external profile at all, and leave the interface in
    state disconnected. I already wanted to do this, but opted out, because it
    was too big of a change in behaviour.

in terms of simplicity: 3 > 2 > 1
in terms of preserving established behaviour: 1 > 2 > 3

Comment 4 Eric Garver 2018-08-28 14:40:11 UTC
From my point of view #3 is what I expect, but I'm not familiar with NetworkManager's APIs and semantics. So I'll let the NM group decide the best path forward. :)

Comment 5 Tomas Dolezal 2018-08-29 16:26:49 UTC
I agree with Eric above, especially the NM semantics.
For this bug however it is sufficient to not allow managing or reporting the profile zone, which on it's own might be ugly w.r.t. NM usage model.

In #3:
 * as a NM user I'd not be able to just modify and then save so-far-unmanaged interface, but that seems to be a corner use case to me.
 * there could be regression in not reporting all present interfaces via NM though.

Comment 6 Thomas Haller 2018-11-15 15:48:59 UTC
An improvement for the oddities of externally managed devices would be bug 1650221: devices would be unmanaged by default unless the user creates a profile for them. That doesn't solve the oddities, but it avoids it in many cases where the user never intended NM to manage the device.

Comment 7 Thomas Haller 2018-11-15 16:03:48 UTC
Related to improving handling of externally-managed devices is bug 1650228.

the advised way before messing with a device manually (which is not marked as unmanaged in NetworkManager) is to mark the device as unmanaged. When doing so, the device should be left to the user in a suitable state.

Comment 8 Marcelo Ricardo Leitner 2019-07-03 15:11:16 UTC
Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

Comment 10 Thomas Haller 2020-03-23 14:40:36 UTC
See also discussion at https://bugzilla.redhat.com/show_bug.cgi?id=1542978

Comment 11 Thomas Haller 2020-03-23 14:41:44 UTC
*** Bug 1542978 has been marked as a duplicate of this bug. ***

Comment 12 Thomas Haller 2020-03-23 15:07:17 UTC
Opened bug 1816202 "Better represent externally managed devices in NetworkManager UI".

This also implies to make it possible to recognize these externally managed devices on D-Bus. That API may also be interesting for firewald to decide what (not) to do.

Comment 16 RHEL Program Management 2021-01-08 07:34:25 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.