Interface connection.permissions set to root user only

Rocky Linux General
1

Hi there

I’m hoping somebody can help. I have some machines running Rocky 8. Recently the servers were restored from a backup to a DR site by our customer and we were having intermittent issues with connectivity.

Long story short it appears that at some point during this process of restoration the primary interface on the boxes switched to the connection permissions being root only - meaning that when logging out of a root session the interface is shut down by network manager and restarted again when logging in.

We have corrected it and it’s now working fine but we also have some Centos 8 machines that were migrated in exactly the same fashion that didn’t exhibit this problem. I have tried searching google but can’t seem to find anything relating to what I have seen and it’s not an issue I have come across before.

Are there scenarios wherby the network manager would switch:

connection.permissions:

to be:

user:root

I was involved in bringing the servers back online, they are a closed system so while the client manages the infrastructure and the VM’s, they have no access to the servers themselves. There were no changes made to the network configuration at any point and all services were up and running.

While i’m happy it’s fixed it would be good to know if the situation we’ve seen is ‘normal behaviour’ or whether it a bug of sorts. Also worthy of mention is that there is a second interface on these boxes but this didn’t suffer the same problem.

Hopefully someone is able to shed some light on this :slight_smile:

Thanks

2

In RHEL and Rocky, Network Manager will (by default) log a lot of information about things like conections going down, so it’s probably worth checking the logs around the exact date/time of where you were seeing the issue.
I don’t understand the part about “connection permissions”. I have not heard of such a thing until now…

3

Hi Gerry, thank you for your response.

Unfortunately I don’t have the logs all the way back to when this started, but what we were seeing in the log files is:

Apr 19 16:39:12 europa-cedsdb systemd-logind[1129]: Removed session 81.
Apr 19 16:39:12 europa-cedsdb NetworkManager[162356]: [1650382752.1230] device (ens192): state change: activated → deactivating (reason ‘connection-removed’, sys-iface-state: ‘managed’)
Apr 19 16:39:12 europa-cedsdb NetworkManager[162356]: [1650382752.1244] manager: NetworkManager state is now CONNECTED_LOCAL

Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2291] policy: auto-activating connection ‘ens192’ (a5979606-4042-421a-af32-3c7ff505ab6f)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2298] device (ens192): Activation: starting connection ‘ens192’ (a5979606-4042-421a-af32-3c7ff505ab6f)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2299] device (ens192): state change: disconnected → prepare (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2302] manager: NetworkManager state is now CONNECTING
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2303] device (ens192): state change: prepare → config (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2311] device (ens192): state change: config → ip-config (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2328] device (ens192): state change: ip-config → ip-check (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb dbus-daemon[1031]: [system] Activating via systemd: service name=‘org.freedesktop.nm_dispatcher’ unit=‘dbus-org.freedesktop.nm-dispatcher.service’ requested by ‘:1.437’ (uid=0 pid=162356 comm="/usr/sbin/NetworkManager --no-daemon " label=“system_u:system_r:NetworkManager_t:s0”)
Apr 20 09:41:56 europa-cedsdb systemd-logind[1129]: New session 82 of user root.
Apr 20 09:41:56 europa-cedsdb systemd[1]: Starting Network Manager Script Dispatcher Service…
Apr 20 09:41:56 europa-cedsdb systemd[1]: Started /run/user/0 mount wrapper.
Apr 20 09:41:56 europa-cedsdb systemd[1]: Created slice User Slice of UID 0.
Apr 20 09:41:56 europa-cedsdb systemd[1]: Starting User Manager for UID 0…
Apr 20 09:41:56 europa-cedsdb systemd[1]: Started Session 82 of user root.
Apr 20 09:41:56 europa-cedsdb dbus-daemon[1031]: [system] Successfully activated service ‘org.freedesktop.nm_dispatcher’
Apr 20 09:41:56 europa-cedsdb systemd[1]: Started Network Manager Script Dispatcher Service.
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2517] device (ens192): state change: ip-check → secondaries (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2520] device (ens192): state change: secondaries → activated (reason ‘none’, sys-iface-state: ‘managed’)
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2524] manager: NetworkManager state is now CONNECTED_LOCAL
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2536] manager: NetworkManager state is now CONNECTED_SITE
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2537] policy: set ‘ens192’ (ens192) as default for IPv4 routing and DNS
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2644] device (ens192): Activation: successful, device activated.
Apr 20 09:41:56 europa-cedsdb NetworkManager[162356]: [1650444116.2650] manager: NetworkManager state is now CONNECTED_GLOBAL

So this shows that when a root session was terminated on the box, the primary interface was shut down/disconnected and was restored again when establishing a root session.

I started to look into the behind the scenes network configuration as on the face of things (given that when i logged in everything was up and running) network connectivity, routing, arp tables etc were all fine.

The output of: nmcli connection show

gave the following:

connection.id: ens192
connection.uuid:
connection.stable-id: –
connection.type: 802-3-ethernet
connection.interface-name: ens192
connection.autoconnect: yes
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1650534191
connection.read-only: no
connection.permissions: user:root

(removed all the other information)

It’s that final line that was the issue. The second interface on the box was unaffected.

when running nmtui and editing the interface in question, there is a check box for ‘available to all users’ that was unticked but this isn’t something that was manually changed.

I have tried and tried to find something to understand why this was changed but so far haven’t been able to track it down.

I’m wondering whether it’s potentially a bug or some kind of protective mechanism in place specifically for Rocky (Centos 8 boxes haven’t displayed the same behaviour despite having all the same actions for the migration carried out on them) when the MAC address of an interface has changed.

Checking that box in the network config has resolved the issue but I would like to just be able to understand why it happened.

Thank you

Luke

4

For reference, a normally created connection has empty permissions:

$ nmcli -f connection.permissions con show enp0s31f6
connection.permissions:                 --

and man nm-settings writes:

permissions
An array of strings defining what access a given user has to this connection. If this is NULL or empty, all users are allowed to access this connection; otherwise users are allowed if and only if they are in this list. When this is not empty, the connection can be active only when one of the specified users is logged into an active session. Each entry is of the form “[type]:[id]:[reserved]”; for example, “user:dcbw:blah”. At this time only the “user” [type] is allowed. Any other values are ignored and reserved for future use. [id] is the username that this permission refers to, which may not contain the “:” character. Any [reserved] information present must be ignored and is reserved for future use. All of [type], [id], and [reserved] must be valid UTF-8.

Format: array of string

Therefore, I suspect created by user or created for user. (Features that I have never knowingly used.)

5

Hi

Thank you, this is what we saw, previously it was fine but then following the server move and subsequent MAC change it appears that (for the primary interface at least) that this setting was switched to be root only, meaning that it was shut down when a root user wasn’t logged into the system. As it wasn’t something that was manually changed at any point I just want to establish the cause of the behaviour so I can understand it better.

6

I have not encountered that permission issue, AFAIK.

I do know that NetworkManager default is to generate connection for each interface that does not have one.
IIRC, the connections are runtime only, unless modified. So recreated on every boot.
There is package NetworkManager-config-server that prevents this auto-generation.

Another peculiarity, related to MAC, is that if the Anaconda installer defines a connection for you, it will set 802-3-ethernet.mac-address and not set connection.interface-name.
However, if one creates connection with nmcli then one must set ifname and can’t set mac-address.
One naturally can modify connection afterwards:

nmcli con mod eno1 connection.interface-name "" 802-3-ethernet.mac-address aa:bb:cc:dd:ee:ff

To summarize: NM does match connections to interfaces and generates additional connections as needed (and if permitted). However, none of that explains why it would restrict permissions.

7

Well, I understand what ‘connection.permissions’ are now, but I mainly use the default connection, which doesn’t have any permissions set. I did create a custom connection as a standard user a while back, and it’s possible this would have been tied to the user. I avoid using ‘root’ as much as possible, so I’ve never seen a connection tied to the root user.

8

Thank you for your replies, it looks like this may be an unknown issue that only arises in very specific scenarios. I will continue the search to see if I can find anything further online.