Steam prompts Network Manager without admin permissions

[Stirdix]

Your system information

• Steam client version (build number or date): Built Jun 8 2021 at 11pm [although problem was a bit earlier; this is attempting a fresh reinstall]
• Distribution (e.g. Ubuntu): Ubuntu 20.04.2 LTS (64 bit)
• Opted into Steam client beta?: No (I think)
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

Whenever I start Steam on my non-admin account, I get a prompt from NetworkManager to change global network settings [which I can't, because I don't have permission]. This prompt cannot be removed so long as Steam is open - closing the window or killing the process just reopens another prompt. Closing the window continues to make a new prompt even after Steam is closed. [Exiting Steam, then killing the process does remove the prompt though.]

Steam then boots up and runs games seemingly just fine. I think there are then issues with cloudsaves, but am not easily able to confirm that. [I tried a fresh reinstall to see if it resolved the issue, but (a) it did not and (b) that caused other problems that I would need to resolve first.]

This is new since something like Monday or Tuesday, so presumably an update (but IDK if it's Steam or Ubuntu). [Also, it's not just me; see also this recent post: https://steamcommunity.com/app/221410/discussions/0/3106901665845459558/]

Steps for reproducing this issue:

Boot Steam on Ubuntu 20.04 on non-admin account [if there are more conditions, I don't know them]

[nhnb]

I can confirm both issues:

• Steam wants to mess with the network settings for unknown reasons
• When rejected, the dialog pops up again and again

Possible workarounds:

• click it away a zillion times. Steam seems to work fine afterwards
• use alt+ctrl+f2 to switch to text console and kill Steam with -9. There are still a couple dialog boxes to click away

The really bad thing here, that you cannot do anything else, use any other application while the permission dialog is up.

VERSION="20.04.2 LTS (Focal Fossa)"
PRETTY_NAME="Ubuntu 20.04.2 LTS"

[Stirdix]

Want to highlight: unlike @nhnb it doesn't lock up my system, nor does it prevent me from doing anything else, it just sticks around annoyingly. [Closing repeatedly also didn't work for me, but maybe I didn't close it enough times.]

Also, an addendum: I use Unity rather than Gnome (when Ubuntu made the swap I stuck to what I was used to), in case that ends up mattering. I don't believe my machine has anything else relevantly distinct from a standard Ubuntu install.

[chewi]

I've seen this on OpenSUSE Leap 15.2 since the recent Steam update and it persisted after upgrading the OS to 15.3. I've worked around it by writing the following to /etc/polkit-default-privs.local although this may be SUSE-specific and I shouldn't have to do it:

org.freedesktop.NetworkManager.settings.modify.system yes

I suspect it wouldn't happen if the connection didn't have the "All users may connect to this network" flag set but I didn't try changing that. Again, I shouldn't have to.

[jmbromley]

I'm also seeing this since the update before the update that takes you to runtime 0.20210518.3 (June 8th 2021).

I can also confirm the steam client specifically trips the polkit rule for org.freedesktop.NetworkManager.settings.modify.system, which in turn asks the user to enter an admin password.

For some distribution set-ups (such as default Ubuntu 20.10) this blocks the desktop environment.

I can also confirm that if you click "cancel" a sufficiently large number of times (order of 50 or so), the message eventually goes away and the client runs normally --- suggesting it really doesn't need the privileges it is requesting.

I would like to reiterate the concerns of others:

• There is already a network connection, Steam should have no need to modify it (and certainly not at a system-wide level).
• Moreover a user should not need sudo privileges to run the Steam client.

Please please revert to the normal behaviour or at least provide a justified reason for the new behaviour together with a better workaround than clicking cancel 50 times. I do not wish to give sudo access to users on my system just so that they can run Steam games, nor do I wish to unnecessarily modify polkit default policies.

[abderrahim]

I just wanted to share something I noticed monitoring the dbus communication:

What steam is doing (and is triggering the "modification of network settings for all users") is a call to org.freedesktop.NetworkManager.Settings.Connection.GetSecrets passing in '802-11-wireless-security', which I understand as trying to get the wifi password. I have no idea why it does that.

[chewi]

Well that's concerning...

[BlockOG]

I can confirm this steam behavior on Ubuntu 20.04.2 LTS It's very very very annoying.

[joaormatos]

I'm also affected on Debian 10. Don't know when it started; haven't used Steam in a while. Very disconcerting behavior from an application that has no business with my system's network configuration.

I worked around it with a file at /etc/polkit-1/localauthority.conf.d/90-silence-steam.conf with these contents:

[Stop steam user from prompting for network permissions]
Identity unix-user:steam
Action org.freedesktop.NetworkManager.settings.modify.system
ResultActive no
ResultInactive no
ResultAny no

Change the steam in the second line to match the user that runs Steam in your system.

• Steam client version: Jul 16 2021, at 18:05:04
• Opted into Steam client beta?: yes
• Distro: Debian 10 "buster" GNU/Linux amd64
• Have you checked for system updates?: Yes

[draeath]

@joaormatos does this allow or reject the request from steam?

If this rejects, you are my hero.

[joaormatos]

@joaormatos does this allow or reject the request from steam?

If this rejects, you are my hero.

Yes, it rejects the request without prompting. See the man page pklocalauthority(8)

But it's rejecting all requests from the specified user, not just Steam. The presumption is that you're running Steam with a user named "steam."

There's probably a better way to do this by more thoroughly isolating Steam from the rest of the system.

[draeath]

Well, ideally Valve puts a setting in somewhere for whatever it is they think they need this access for.

But I'll take what I can get.

[codebori]

So this bug still exists. Why does this page even exist if it is being ignored? Or is there any word from Valve somewhere else about this serious security issue?

[StefanBruens]

@kisak-valve - as you are apparently monitoring this, you can please specify why steam needs to modify network settings?

[bendlas]

Looking at https://github.com/flathub/com.valvesoftware.Steam/blob/9f376cf5adf73d5d1777c55d0283ea48567b3e4b/com.valvesoftware.Steam.yml#L23 this may be some stray SteamOS functionality leaking through.

I can confirm that on NixOS, the flatpak version (as well as regular version) of Steam also shows this behavior.

I can also confirm that with the flatpak version, you can selectively block dbus access from steam to networkmanager, by running

flatpak override --system --system-no-talk-name=org.freedesktop.NetworkManager com.valvesoftware.Steam

without compromising other dbus-based functionality.

When asking around, I have learned that on fedora no admin popup has been observed (probably due to more relaxed security), which would explain the lack of larger interest on this ticket.

This whole debacle suggests to me that it would be prudent to increase and tighten the sandboxing for steam and other proprietary software across all distribution mechanisms.

[bendlas]

This is related to a startup slowdown in case of missing NM https://github.com/ValveSoftware/steam-for-linux/issues/4979

Flatpak actually enabled NM access to work around https://github.com/flathub/com.valvesoftware.Steam/commit/b56d7b72bc1d71ba9d8dc9d3c45dd80255bd7362

@kisak-valve please help us get this fixed properly, ~we want to keep operating under a good-faith assumption and keep accepting your help with mainstreaming the Linux desktop. But Valve is going to have to realize that shit like this doesn't fly here the same way it flies on Windows and Mac.~ this is a very bad look for Valve, security-wise.

EDIT: Everybody, please excuse the previously strong wording. That was written in the heat of the moment.

[adolson]

This is annoyingly still occurring on a fresh Steam + Debian install I set up for my son. The Steam client should simply detect the system policy and disable its network management features, if need be, rather than pop up admin authentication requests, IMO. Anyhow, thanks for the workarounds mentioned, whoever mentioned them.

[Maryse47]

Another workaround for experienced users: if you use NetworkManager with iwd backend then you can simply remove wifi password from NM config and it should still work as iwd can connect with only pre-shared key. This way you don;t have to block dbus access and shouldn't get the aforementioned startup delay.

[BugReporterZ]

I stumbled upon this problem recently on OpenSUSE Tumbleweed and it was very annoying. However there are two simple workarounds: a temporary one and a permanent one (i.e. a possible solution) with security implications that are not entirely clear to me:

Method 1: Start Steam with Wifi disabled, then enable it afterwards. It will not ask for admin rights anymore for that session (but it will next time).

Method 2: In KDE Plasma 5, in the NetworkManager GUI (System Settings > Network > Connections), Disable "All users may connect to this network" for your Wifi connection, and add your own user to the allowlist in Advanced. Steam will not ask for admin rights anymore.

[draeath]

This seems to have gotten worse with the latest Steam client update.

Now it's asking me periodically (at random, it feels) when Steam is running.

[vatrat]

Encountering this issue on current OpenSuSE Tumbleweed. I tried to resume from suspend after my wifi went out during a storm (knocked down some power lines) and steam began continuously asking for password. I couldn't get it to stop, so I had to switch to a tty and reboot. I don't have any nonstandard wifi configuration, so simply put: how is this still an issue? It's been almost a year with multiple confirmations and suggested workarounds, but this is clearly an issue with the steam client's own code. With all the work put into proton and Vulcan, how are we messing up the little things?

Edit: I now see that there are 2000 open issues. I retract my statement.

[efade]

Still have this issue. With the latest update Steam even couldn't connect to the network even though my network was fine.

[dhjw]

Yeah, I'm having this problem on Ubuntu 20.04 after an update today. Even if I enter my password for sudo it just keeps popping up. I can't do anything unless I hit cancel a lot.

Update: I was having a problem with sudo in any GUI dialog, which I fixed with sudo usermod -aG sudo $USER (my user is also in /etc/sudoers with nopasswd). I also opted into the Steam client beta. One of these things stopped the Steam prompt. I think it was the usermod, though I thought I was already in the sudo group before...

[c00ldude1oo]

Happening on lubuntu 22.04 LTS fresh install. Can't let anyone else play on it without me being around to enter password..

[dagewa]

Happening on lubuntu 22.04 LTS fresh install. Can't let anyone else play on it without me being around to enter password..

Yeah, this is the critical problem. Steam is on the computer connected to my TV so that the kids can play games. No way am I giving them sudo access!

[chewi]

Don't forget the workaround I mentioned. It's still working here.

[leklachu]

+1 for wanting an answer of why Steam is doing this. I also assume misunderstanding/bug/incompetence over malice, but being not open source means we rely on trusting Valve about their software, and they wouldn't be the first company to snoop on wifi passwords and later go, "oh no! I'm sure we didn't mean to do that, it was... a mistake"

I'm very much in favour of this being fixed correctly -- which I, in my limited wisdom presume means either Steam not doing this, or having a very clearly documented reason -- not by smoothing it over for convenience (say by bypassing the policykit restriction willy-nilly by default)

[bundyo]

They seem to be iterating over the saved WiFi connections. If even one is set to be usable from all users, the dialog is triggered (as all users settings can't be modified without root credentials). Removing all "all users" ticks will skip the dialog. I guess this comes from SteamOS, where they need to manage its connections.

[leklachu]

But outside of SteamOS, Steam should not be managing WiFi connections. Perhaps this behaviour can be disabled for when the system's not running SteamOS.

all users settings can't be modified without root credentials ... Removing all "all users" ticks will skip the dialog.

This is exactly what we don't want: giving Steam easier access to system things it shouldn't be touching. If Steam insists on meddling with wifi connections, then IMHO we should treat it as an untrusted app, and all swtich to using it within Flatpak/similar and having Flatpak block that stuff.

[chewi]

After hitting this on my daughter's OpenSUSE system, I'm now hitting it on my wife's, except the workaround I applied previously doesn't seem to work here. I can't figure out why. I wish they'd just fix it already.

EDIT: Ah, I forgot to note that you also need to run /sbin/set_polkit_default_privs.

[codebori]

As a "workaround" I ignore the pop-up. Steam will start eventually as normal.

I do agree it should be treated as an untrusted app if they don't fix this though.