core: ignore unmanaged devices for explicit activation request depending on multi-connect

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 plain

  $ nmcli connection up "$PROFILE"

where NetworkManager searches for a suitable device -- depending on
multi-connect setting of the profile.

The idea is, that a profile with "multi-connect=single" is expected
to sufficently and uniquely match a device, based on matching properties
like "connection.interface-name". In that case, an explicit activation
request from the user shows the intent to manage the device.
Note that it's hard to understand whether the profile really uniquely
selects a particular device. For example, if the profile doesn't specify
"connection.interface-name", it might still uniquely identify
an ethernet device, if you only have one such device.

On the other hand, with "connection.multi-connect" other than "single",
it is very much expected that the profile does not strictly match
one device.

Change the behavior here for multi-connect profiles. This allows the
user to block individual devices from activation via

  $ nmcli device set "$DEVICE" managed not

A subsequent

  $ nmcli connection up "$MULTI_PROFILE"

will not consider "$DEVICE" as suitable candidate for activation.

Likewise, in the future we may want to add a

  $ nmcli connection up --all "$MULTI_PROFILE"

command, to activate the profile on all suitable device.
In that case again, unmanaged devices probably also should be skipped
for multi-connect profiles.

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

1 files changed, 35 insertions, 2 deletions

diff --git a/src/nm-manager.c b/src/nm-manager.c
index 2714690b6b..d2fad95519 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -3404,10 +3404,43 @@ 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. And explicit user-request shows sufficent user
+		 * intent to make the device managed.
+		 * That is also, because we expect that such profile is suitably tied
+		 * to the intended device. So when an unmanaged device matches, the user's
+		 * intent is clear.
+		 *
+		 * For multi-connect != single devices that is different. The profile
+		 * is not restricted to a particular device.
+		 * For that reason, plain `nmcli connection up "$MULIT_PROFILE"` seems
+		 * less suitable for multi-connect profiles, because the target device is
+		 * left unspecified. Anyway, if a user issues
+		 *
+		 *   $ nmcli device set "$DEVICE" managed no
+		 *   $ nmcli connection up "$MULIT_PROFILE"
+		 *
+		 * then it is reasonable for multi-connect profiles to not consider
+		 * the device a suitable candidate.
+		 *
+		 * This may be seen inconsistent, but I think that it makes a lot of
+		 * sense. Also note that "connection.multi-connect" work quite differently
+		 * in aspects like activation. E.g. `nmcli connection up` of multi-connect
+		 * "single" profile, will deactivate the profile if it is active already.
+		 * That is different from multi-connect profiles, where it will aim to
+		 * activate the profile one more time on an hitherto disconnected device.
+		 */
+		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