Proton 5.13 on SteamOS 2 needs either bubblewrap or kernel.unprivileged_userns_clone=1

[frioux]

Your system information

• Steam client version: Dec 20, 2020 at 23:07:39
• SteamOS version: SteamOS 2.0 update 1:2.195
• Opted into Steam client beta?: Yes
• Opted into SteamOS beta?: Yes]
• Have you checked for updates in Settings > System?: Yes

Please describe your issue in as much detail as possible:

I try to start any game using proton 5.13 and get a very brief flash and then the game does not start.

Steps for reproducing this issue:

1. Install any game (Have reproduced with 7 games today, including Control and Death Stranding)
2. Make sure Proton 5.13 is selected
3. Start Game

Bizarrely, setting PROTON_LOG=1 doesn't work for 5.13, but does for 5.0. This makes me think that somehow the installation of 5.13 is broken, but I'm just using it as it gets automatically installed by SteamOS.

[kisak-valve]

Hello @frioux, in general, SteamOS 2.0's video drivers are too old for Proton support, but it shouldn't fail without trying and generating a Proton log. This hints that there's an issue with Pressure Vessel setting up the Steam Linux Runtime - Soldier container. From a desktop session:

---

Please could you show us a log of what pressure-vessel is thinking, and exactly what happens? You can do this without involving Proton (which should make things a bit simpler) like this:

cd /path/to/SteamLinuxRuntime_soldier
PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log

and then send container.log as a gist. You can edit/censor the log if there's anything in it that you consider private, as long as it's obvious where it has been edited, for instance replacing your username with REDACTED.

The SteamLinuxRuntime_soldier directory will be in one of your Steam libraries. The most likely place is ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier if you haven't reconfigured the installation path.

Also please show us the full system information (Help -> System Information in Steam), after waiting for the diagnostic tools to finish thinking about what drivers you have. Again, you can edit/censor it if you need to, and please send it as a gist.
(from #312 (comment))

[frioux]

annoyingly on steamos the desktop usage is actually a different user, so steam-runtime-system-info is not in my path. I suspect lots of other stuff would fail for that reason. will try to figure something out tho

…

On Wed, Dec 23, 2020, 8:42 AM kisak-valve ***@***.***> wrote: Hello @frioux <https://github.com/frioux>, in general, SteamOS's video drivers are too old for Proton support in general, but it shouldn't fail without trying and generating a Proton log. This hints that there's an issue with Pressure Vessel setting up the Steam Linux Runtime - Soldier container. From a desktop session: ------------------------------ Please could you show us a log of what pressure-vessel is thinking, and exactly what happens? You can do this without involving Proton (which should make things a bit simpler) like this: cd /path/to/SteamLinuxRuntime_soldier PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log and then send container.log as a gist <https://gist.github.com/>. You can edit/censor the log if there's anything in it that you consider private, as long as it's obvious where it has been edited, for instance replacing your username with REDACTED. The SteamLinuxRuntime_soldier directory will be in one of your Steam libraries. The most likely place is ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier if you haven't reconfigured the installation path. Also please show us the full system information (Help -> System Information in Steam), after waiting for the diagnostic tools to finish thinking about what drivers you have. Again, you can edit/censor it if you need to, and please send it as a gist <https://gist.github.com/>. (from #312 (comment) <#312 (comment)> ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#342 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAB7Y6AQKZELQVTUEL4SK3SWIMYLANCNFSM4VHGF4AQ> .

[frioux]

ok here's the gist: https://gist.github.com/frioux/52b5d4da2ec6d1b954308875fac113aa

I can run the suggested command but this seems like something that should be pushed into steamos to fix proton 5.13 to me. (Will try to get the rest of the info you asked for too)

[kisak-valve]

Thanks, I think we can stop here. bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. is the key detail from the log.

[frioux]

Cool. For future reference, it's also really difficult to get the system information on steamos since you can only run steam in big picture mode (as far as I can tell.)

[smcv]

This is really a SteamOS bug rather than a Steam Runtime bug: now that the Steam Runtime needs container stuff, a SteamOS update should either install bubblewrap, or set the sysctl to allow unprivileged users to create new namespaces. We can't do that as part of Steam Runtime installation because it's a privileged action (requires root), so it has to be done at the OS level.

We do automatically install bubblewrap on Debian (in the official Valve package if Steam is run as someone who can sudo, or in the Debian package via Recommends), but we don't have a way to make SteamOS install it automatically, other than pushing out a SteamOS update.

@kisak-valve, please could you retitle this to stop non-SteamOS users jumping onto it? Something like: "Proton 5.13 on SteamOS 2 needs either bubblewrap or kernel.unprivileged_userns_clone=1".

[sipaktli]

Okay, I have been reading your justification for UNs, and it is valid reasoning, but security as you yourself mention was an afterthought. Security should never be an afterthought.

May I suggest that when the client lacks proper permissions, the client itself links to a well articulated, well referenced article where you resume the justification for your requirement? Clear communication can save a lot of hassle.

Also, I would like to suggest adding an apparmor profile at least, and to run steam as its own user. Here is an example:

# /etc/apparmor.d/steam
#include <tunables/global>

profile steam /opt/steam/steam {
    # Basic permissions
    #include <abstractions/base>
    #include <abstractions/user-tmp>

    # Filesystem access
    /opt/steam/steam/** rw,
    /opt/steam/steam/steam.sh ix,
    /opt/steam/steam/steamapps/** rw,
    /opt/steam/steam/steamapps/compatdata/** rw,
    /opt/steam/steam/steamapps/shadercache/** rw,
    /opt/steam/steam/steamapps/common/** rw,

    # Allow access only to /home/steam
    /home/steam/** rw,

    # Restrict access to other /home directories
    /home/** rix,

    # Allow temporary directory access
    /tmp/** rw,

    # Network access
    network inet stream,
    network inet dgram,

    # Log files
    /var/log/steam/** rw,
    
    # Allow ptrace for debugging
    capability sys_ptrace,
    
    # System configuration
    /etc/ld.so.cache r,
    /etc/ld.so.conf r,
    /usr/lib/** r,
    /usr/share/** r,
}