Allow other Snap apps to use steam-support, instead of just Steam

snapd
1

I want to discuss a serious problem: the lack of access for game launchers to the steam-support plug.

Launchers like Heroic, Minigalaxy, Bottles, and Zordeer use Wine/Proton and primarily the UMU launcher.

The UMU launcher mimics the Steam environment, even using steamrt3, to ensure games run correctly. This avoids execution problems and facilitates the creation of Snap versions, as developers won’t need to deal with multiple 32-bit libraries.

However, the UMU launcher cannot function on Snap without the steam-support plug, meaning these launchers cannot be released on the Snap Store.

And I noticed in Minigalaxy that the steam-support plug is also important for native Linux games.

I understand that steam-support provides access to many things, but it doesn’t make sense to treat Steam as safe while these launchers are treated as a risk.

Steam allows the execution of .exe files from unknown sources, just like these launchers, so they don’t pose a greater risk. If you trust Steam, it doesn’t make sense not to trust these launchers.

Especially considering that they have open source code, this could even be a requirement for an app that isn’t Steam to have access to the steam-support plug, the open source code, since this way they can guarantee that nothing wrong is being done.

Opening the Snap Store, having a section about games, and within the games section having a section about game launchers, in the plural, but only Steam existing in that section, is very sad. It makes users dependent on installing this type of app outside of the Snap Store.

Considering the users, a Snap version will be much more reliable and easier to use than the same app published in a .deb version.

Furthermore, it’s very contradictory that the joystick plug exists, steam-support exists, several emulators are available in the Snap Store, RetroArch has an automatic connection with the joystick plug, but only the Steam launcher can work.

3 Likes
2

The Snap Store section I mentioned about game launchers is this one; as you can see, all the other options show at least 3 apps, but the game launcher section only shows Steam.

It’s not just a mistake; there really isn’t anything else to show besides Steam.

Captura de imagem_20260112_200356
Captura de imagem_20260112_2003561600×900 164 KB

1 Like
3

I understand the reasons for not granting access to the Steam-Support interface to anyone outside of Canonical. I deeply respect the commitment to security and strict confinement made by Canonical; it’s actually one of the reasons why I ended up choosing Snap over other formats. However, as I’ve already mentioned in this thread, the gaming experience on Linux remains incomplete if other launchers cannot be accessed. 2026 promises to be a year of significant growth in Linux gaming, so resolving this issue should be a priority. If any of you create a post to support the development of an interface that allows game launcher Snaps more easily, let me know so I can head over and support it. In the meantime, perhaps someone from Canonical could create and mantain a Snap for Heroic Games Launcher…

Thanks. To be clear, these are all just suggestions. I don’t mean to come across as impatient.

2 Likes
4

I imagine that in the case of Steam support, there’s a bit too much caution involved.

I suppose the idea of ​​the plug being only for Steam is because Steam/Valve is trustworthy, but what Steam uses to run games are open-source projects, just like other launchers do.

Steam allows users to run things from unknown sources, just like other launchers, so the security risk isn’t about the launchers or Wine/Proton/UMU, but rather about the freedom the user has.

Launchers like Heroic, Minigalaxy, Bottles, Zordeer, and UMU don’t pose a greater risk than Steam.

With the UMU launcher and Wine 11, it will be much easier to get these launchers working; this is the best time for these launchers to be released on the Snap Store.

5

An important piece of information I noticed is that without the “steam-support” plug, Feral gamemode throws this error several times when trying to be used.

GameMode ERROR: D-Bus error: Could not call method 'UnregisterGame' on 'org.freedesktop.portal.Desktop': Could not get pidns: Could not fstatat ns/pid: Não é um diretório
gamemodeauto: D-Bus error: Could not call method 'UnregisterGame' on 'org.freedesktop.portal.Desktop': Could not get pidns: Could not fstatat ns/pid: Não é um diretório

After connecting the steam-support plug, this error disappears.

6

I’m testing it on Zordeer using Wine and Proton, since the “steam-support” plug can’t be used, the game mode can’t be used either.

For launchers like Zordeer, having access to “steam-support” and thus being able to use game mode makes sense, since the “steam-support” plug was created to run native Linux games and/or games via Wine/Proton, which is the purpose of this type of app.

But I imagine it would make sense to later create a separate plug for Feral game mode, since there are emulators that try to use it, but it wouldn’t make much sense to give the “steam-support” plug to an emulator.

7

I think the problem is with the trust model.

It has been noted that the steam-support interface grants very wide access to the host system. Given that the snap is published by Canonical, there’s a review process that happens in the open at Pull requests · canonical/steam-snap · GitHub . AFAIU there was some collaboration between the team that published the snaps and folks who work on bubblewrap. The technology is known and proven and there is a level of trust between the snapd team providing the interface, the team publishing the snap and the team who works on confinement for steam.

Now run this scenario, would you feel confident to connect the interface manually after installing a snap published under some random anonymous account? Probably not. Neither would the reviewers be inclined to allow this to happen automatically and persist for future revisions of the snap.

It’s not to say that the interface could not be granted at some point. I think it would be granted, if said snap was to be published by a party which the reviewers team (including the security folk) can trust to be accountable for and who have a track to prove it. If, say Heroic upstream, was involved in publishing the snap I think it would certainly make the process easier.

1 Like
8

I’m trying to fix the Snap version of Heroic. I managed to start, log in, download games, run games, and create .desktop shortcuts, but it’s absolutely necessary that the steam-support plugin be used. I also want to release a Snap version of the UMU launcher, which is basically umu-run using the libraries that Snap provides through mesa-2404 and kf6-core24.

In other words, it would also be possible for native apps to call UMU Snap, which in many cases would avoid automatic connection requests to steam-support, since simpler launchers or those that don’t want a Snap version could simply use the umu-run Snap. This would avoid adding 32-bit dependencies to the system.

My pull request in the Heroic Games Launcher repository is this: Simplifying snapcraft.yaml by Kyuyrii · Pull Request #5113 · Heroic-Games-Launcher/HeroicGamesLauncher · GitHub

I published a tar.gz package with the generated .snap here: Release 2.18.1_2026-01-08 · Kyuyrii/Test-Snap-Heroic · GitHub

9

In this case, I’m not talking about any app being able to use the steam-support plug, nor am I talking about connecting it after installing a Snap app downloaded from the Snap Store.

But rather about some Snap apps, besides Steam, being able to receive the automatic connection.

I publish Zordeer and Minigalaxy, and I’m also trying to publish umu-run. Of these three, only Zordeer is an unknown app, but it has open source code, uses Wine/Proton/UMU, and I’m the developer. I know I’m not very well-known, but it wouldn’t make any sense for me to try to do something malicious with the steam-support plug.

I started making Snap apps because I wanted the experience with Snap and Ubuntu to be better. Initially, it was about visual consistency, since there weren’t many theme Snaps or they required commands to work. After a few months, it became possible to receive the automatic connection for theme Snaps without being their developer. This greatly improved the user experience.

I know there’s a huge difference between Snap themes receiving automatic connection and Snap launcher versions receiving automatic connection to the steam-support plug.

But the issue is user experience; I’m hoping for a change to improve the user experience with Snap and Ubuntu.

Obviously, I don’t expect access to the steam-support plug to be given to every Snap, but we have to start somewhere.

10

I highly doubt you will ever get permission to use steam-support on anything but steam, it was clearly designed for that single app use case and grants way more permissions than any app game launcher would need …

Creating a game-launcher interface that does not drop 95% of the confinement (please see the source code comments of the interface to see what I mean…) might be acceptable though …

Alternatively if this does not work because nobody steps up to even start work on such an interface, it would even be more realistic to allow game launchers from trusted and verified upstreams as a new category of classic snaps than to allow a completely open strict interface like steam-support to random uploaders IMHO …

2 Likes
11

steam-support for other apps could be just a temporary solution for Heroic Games Launcher, Minigalaxy, and umu-run.

Zordeer isn’t as well-known as those three, but what it does is basically facilitate the use of Wine/Proton/UMU. It could be used for testing, since it allows for freer use of Wine and is simple to modify.

The umu-run Snap is just a UMU launcher within a Snap; it could be used by native launchers or AppImages while the game-launcher interface is unavailable.

In this case, the difference with using umu-run within a Snap is that mesa-2404 already provides what UMU needs to function, so it wouldn’t be necessary to add 32-bit dependencies to the system.

12

I am still getting familiar with Snap interfaces, but as a user, could I manually connect the ‘steam-support interface’ for the Heroic Games Launcher Snap in case that privilege is not granted to its maintainer, or would it still not be accepted? What I mean is, even with this privileged interface, I understand that the Snap wouldn’t have more permissions than the .deb or the .flatpak versions, or am I mistaken?

13

There are a few things that prevent a Snap from being published on the Snap Store; the steam-support plug is one of them.

So currently, the only way to use a Snap version of the Heroic Games Launcher is by installing a created .snap file and then connecting the necessary plugs.

This makes installation and updates more complicated, defeating the purpose of creating a Snap version.

1 Like
14

I tried using umu-run without steam-support; mount-observe is necessary to transfer steamrt3.

Without mount-observe, this error occurs:

Traceback (most recent call last):
  File "/snap/umu-run/x5/usr/bin/umu-run", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/__main__.py", line 90, in main
    return umu_run(args)
           ^^^^^^^^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_run.py", line 869, in umu_run
    check_env(env, session_pools)
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_run.py", line 140, in check_env
    get_umu_proton(env, session_pools)
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_proton.py", line 85, in get_umu_proton
    tmpdirs: SessionCaches = (get_tempdir(), Path(tmpcache))
                              ^^^^^^^^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_util.py", line 329, in get_tempdir
    _fsck_path(tmpdir, "tmpfs") and stat.f_frsize * stat.f_blocks >= TMPFS_MIN
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_util.py", line 309, in _fsck_path
    return any(line for line in lines if line[1] == dst and line[2] == filesystem)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_util.py", line 309, in <genexpr>
    return any(line for line in lines if line[1] == dst and line[2] == filesystem)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/umu-run/x5/usr/lib/python3/dist-packages/umu/umu_util.py", line 286, in _get_lines_split
    with path.open(mode="r", encoding="utf-8") as file:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/pathlib.py", line 1015, in open
    return io.open(self, mode, buffering, encoding, errors, newline)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/proc/mounts'

After connecting mount-observe and trying to start something, this error occurs:

pressure-vessel-wrap[699428]: E: Child process exited with code 1: bwrap: Can't read /proc/sys/kernel/overflowuid: Permission denied
15

I added all the plugs used by Steam Snap to umu-run and connected them all, except for steam-support, but it still didn’t work and gave the same error as before:

pressure-vessel-wrap[721150]: E: Child process exited with code 1: bwrap: Can't read /proc/sys/kernel/overflowuid: Permission denied
16

I also tried allowing this location to be read using the system-files interface, I added that but it made no difference:

plugs:
  bwrap:
    interface: system-files
    read:
      - /proc/sys/kernel/overflowuid
17

I cleared the data, removed /overflowuid from the location, and tried again, but I got this error:

pressure-vessel-wrap[725364]: E: Child process exited with code 1: bwrap: Creating new namespace failed: Permission denied

I searched for bwrap in the snapd repository, found very little, and all of it involved steam-support, no other interface.

And in this case, I’m only testing the UMU launcher that runs games via Proton; the steam-support plug also interfered with something involving native Linux games, so much so that Oxenfree only opened on the Minigalaxy after connecting steam-support.

18

From what I’ve tested, native games are more problematic, whether on Minigalaxy or Heroic.

I suppose it’s better to focus on Wine/Proton/UMU for now, since their behavior is more consistent.

Native games can be run outside of launchers.

But launchers are really necessary for games via Wine/Proton/UMU, since they handle the commands to run the games, as well as downloads, installations, prefixes, etc.

So I imagine that for now the ideal would be to focus on Heroic, Zordeer, and the UMU launcher. In this case, the snaps heroic, zordeer, and umu-run.

19

@Yasirel

Yes, it’s just that the distribution of the snap must not via the Store but from some other channels.

My guess would be DEB > steam-support interface snaps > Flatpak, but I might be wrong.

2 Likes