core: ignore unmanaged devices for explicit activation request with multi-connectth/device-availability

When a device is unmanaged, an explicit activation request can
still activate it.

In particular, that is the case for

  nmcli connection up "$PROFILE" ifname "$DEVICE"

It is also the case, for

  nmcli connection up "$PROFILE"

alone, where NetworkManager searches for a suitable device.

Previously, that would also always consider unmanaged devices
as suitable candidates. I think that makes sense, as usually
a profile is strictly tied to a device via matches like
"connection.interface-name".

However, for profiles with "connection.multi-connect" not "single",
it seems this behavior is not best. Here, the profile is commonly
not tied to one device, but multiple. So, we probably should not
consider unmanaged devices as suitable candidates.

Change the behavior for such profiles. Note, that now the behavior
differs depending on "connection.multi-connect", which can be seen as
inconsistancy. I think it is preferable, because exactly a
multi-connect "single" profile indeed should be tied to one device.
Which is for example what `nmcli connection add` suggest, by requiring
an "ifname" argument. If the profile is tied to a device, the user's
intent is clear and it should not require an explict

  nmcli device set "$DEVICE" managed yes

call first.

https://bugzilla.redhat.com/show_bug.cgi?id=1639254

1 files changed, 25 insertions, 2 deletions

diff --git a/src/nm-manager.c b/src/nm-manager.c
index 1e0a0c44cc..c5c33f9d6c 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -3404,10 +3404,33 @@ nm_manager_get_best_device_for_connection (NMManager *self,
 	if (!connection)
 		connection = nm_settings_connection_get_connection (sett_conn);
 
-	flags = for_user_request ? NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST : NM_DEVICE_CHECK_CON_AVAILABLE_NONE;
-
 	multi_connect =  _nm_connection_get_multi_connect (connection);
 
+	if (!for_user_request)
+		flags = NM_DEVICE_CHECK_CON_AVAILABLE_NONE;
+	else {
+		/* if the profile is multi-connect=single, we also consider devices which
+		 * are marked as unmanaged (but where an explicit user-request could overrule
+		 * the decision).
+		 *
+		 * We do that, because commonly a multi-connect=single device is explicitly tied
+		 * to the right set of devices, so when the user explicitly activates the profile
+		 * on an unmanaged device, the command should be honored.
+		 *
+		 * For multi-connect != single, the profile is intentionally not tied to one
+		 * device, but multiple. Quite possibly, the plain `nmcli connection up $PROFILE`
+		 * call also doesn't make much sense, and the user should always explicitly select the
+		 * device. Anyway, in a multi-connect scenario, we don't want to conisder unmanaged
+		 * devices as suitable candidates.
+		 *
+		 * This can be seen as inconsistant, but I think it ultimately makes more sense.
+		 */
+		if (multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE)
+			flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST;
+		else
+			flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST & ~_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_OVERRULE_UNMANAGED;
+	}
+
 	if (   multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE
 	    && (ac = active_connection_find_by_connection (self, sett_conn, connection, NM_ACTIVE_CONNECTION_STATE_DEACTIVATING, &all_ac_arr))) {
 		/* if we have a profile which may activate on only one device (multi-connect single), then