Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - Fails to attach to currently running steam on flatpak instance #1264

Open
erkinalp opened this issue Mar 13, 2024 · 11 comments
Open
Labels
bug Minor issue

Comments

@erkinalp
Copy link

Describe the bug
Fails to attach to currently running steam on flatpak instance

To Reproduce
Steps to reproduce the behavior:

  1. Pick your modding profile
  2. Click on "start modded"
  3. See error
Steam on Linux now requires the ability to create new user namespaces.

If the file /proc/sys/kernel/unprivileged_userns_clone exists, check that
it contains value 1.

If the file /proc/sys/user/max_user_namespaces exists, check that its
value is high enough.

This requirement is the same as for Flatpak, which has more detailed
information available:
https://github.com/flatpak/flatpak/wiki/User-namespace-requirements

despite there is already a steam on flatpak instance running

Expected behavior
"Start modded" attaches to the existing instance of steam if any.

Screenshots
not necessary

Additional context
Ubuntu 24.04, r2modman app image, steam flatpak, amd64, UEFI

@erkinalp erkinalp added the bug Minor issue label Mar 13, 2024
@erkinalp
Copy link
Author

And said configuration values for user namespaces are already set correctly

@bsmnthppr
Copy link

Having the exact same issue on the .deb installation of Steam on Ubuntu 24.04

@fonikz
Copy link

fonikz commented May 18, 2024

Is this possibly related to 24.04 security features? Are you all running --no-sandbox?

Unprivileged user namespace restrictions
Unprivileged user namespaces are a widely used feature of the Linux kernel, providing additional security isolation for applications, and are often employed as part of a sandbox environment. They allow an application to gain additional permissions within a constrained environment, so that a more trusted part of an application can then use these additional permissions to create a more constrained sandbox environment within which less trusted parts can then be executed. A common use case is the sandboxing employed by modern web browsers, where the (trusted) application itself sets up the sandbox where it executes the untrusted web content. However, by providing these additional permissions, unprivileged user namespaces also expose additional attack surfaces within the Linux kernel. There has been a long history of (ab)use of unprivileged user namespaces to exploit various kernel vulnerabilities. The most recent interim release of Ubuntu, 23.10, introduced the ability to restrict the use of unprivileged user namespaces to only those applications which legitimately require such access. In Ubuntu 24.04 LTS, this feature has both been improved to cover additional applications both within Ubuntu and from third parties, and to allow better default semantics of the feature. For Ubuntu 24.04 LTS, the use of unprivileged user namespaces is then allowed for all applications but access to any additional permissions within the namespace are denied. This allows more applications to more better gracefully handle this default restriction whilst still protecting against the abuse of user namespaces to gain access to additional attack surfaces within the Linux kernel.

@Sinterso
Copy link

Is this possibly related to 24.04 security features? Are you all running --no-sandbox?

Unprivileged user namespace restrictions
Unprivileged user namespaces are a widely used feature of the Linux kernel, providing additional security isolation for applications, and are often employed as part of a sandbox environment. They allow an application to gain additional permissions within a constrained environment, so that a more trusted part of an application can then use these additional permissions to create a more constrained sandbox environment within which less trusted parts can then be executed. A common use case is the sandboxing employed by modern web browsers, where the (trusted) application itself sets up the sandbox where it executes the untrusted web content. However, by providing these additional permissions, unprivileged user namespaces also expose additional attack surfaces within the Linux kernel. There has been a long history of (ab)use of unprivileged user namespaces to exploit various kernel vulnerabilities. The most recent interim release of Ubuntu, 23.10, introduced the ability to restrict the use of unprivileged user namespaces to only those applications which legitimately require such access. In Ubuntu 24.04 LTS, this feature has both been improved to cover additional applications both within Ubuntu and from third parties, and to allow better default semantics of the feature. For Ubuntu 24.04 LTS, the use of unprivileged user namespaces is then allowed for all applications but access to any additional permissions within the namespace are denied. This allows more applications to more better gracefully handle this default restriction whilst still protecting against the abuse of user namespaces to gain access to additional attack surfaces within the Linux kernel.

Hello, could you explain how exactly the "--no-sandbox" argument is supposed to be used? This is literally the only reference I've managed to dig up to my issue and I am quite new to Ubuntu.

@blobmochi
Copy link

I have run both the appimage and .deb versions of r2modman on Ubuntu 24.04 with the --no-sandbox argument and it hasn't been able to launch the game, the mods work launching from Steam with the command provided when you go to the help section of the application. Haven't found another way to solve this.

@Sinterso
Copy link

I have run both the appimage and .deb versions of r2modman on Ubuntu 24.04 with the --no-sandbox argument and it hasn't been able to launch the game, the mods work launching from Steam with the command provided when you go to the help section of the application. Haven't found another way to solve this.

Yeah, hail marry'd adding R2modman to my steam library with the command argument in quotes did it for me as well. Curiously, steam elected to grab R2modman from the /opt directory, and I recall never specifying a location when installing the .deb.

@joecot
Copy link

joecot commented May 30, 2024

Using the command line argument in help to launch from steam directly also didn't work for me. I ended up just turning the namespace confining off using these instructions
https://steamcommunity.com/sharedfiles/filedetails/?id=3252065908

@RyanEskridge
Copy link

Using the command line argument in help to launch from steam directly also didn't work for me. I ended up just turning the namespace confining off using these instructions https://steamcommunity.com/sharedfiles/filedetails/?id=3252065908

Could this be game dependent? I just launched Risk of Rain 2 using this method. Mods load and everything seems to work as intended.

@OMGhixD-OG
Copy link

OMGhixD-OG commented Jun 8, 2024

I encounter the same issue when using the mod manager for Lethal Company. I too was on the flatpak steam and decided to uninstall and use the Debian version

sudo apt install steam-installer

i then went and retried to launch lethal company with modded profile through r2modman with no success and the same error occurred.

My solution was to get the set launch parameters for modded. And put that into custom launch parameters on steam and the game in question. Then i booted the game through steam and everything worked fine.

for now, r2modman is great for downloading mods and managing the profile, but you cannot start the game through the application at all. So it becomes quite the goosechase.

referance from my post on a thread on r2modman's discord

I just wanted to add my solution to this thread.
I've been searching everywhere for a fix. i linked all of it down to it being flatpak steam. (which doesnt neccessarily have to be the case, see the bottom of the post)

I'm currently on Ubuntu 24.04, with a ryzen 5 5600x CPU and intel arc A750 GPU.

I ended up deleting flatpak steam, and installed the debian version by doing sudo apt install steam-installer

From there i installed my game (lethal company) and went over to R2Modman that i run through GearLeveli then went down to launch set launch parametersand copied the "Modded" line.

Example: "--doorstop-enable true --doorstop-target "Z:/home/rob/.config/r2modmanPlus-local/LethalCompany/profiles/RE NA/BepInEx/core/BepInEx.Preloader.dll" --r2profile "RE NA""

I then went into steam and right click on lethal company, hit properties and pasted this into the launch parameters. I then start the game through Steam and woallah, my game boots and mods load.

Is this inconvenient? Yes very.. Have i found another solution that is more fluent/efficient? Not at all.

I guess this is a bugreport as well? Idk if this is a issue with Steam or with R2Modman tho. But my fingers are tilting over at R2Modman.

@KukicVidan
Copy link

I use r2modman just so i can download and update mods...ten manualy replace them into valheim folder /bepinex/plugins and start game ...thats it

@KukicVidan
Copy link

Update: I just downloaded .deb version (for my system ofc) and added it to steam libery as a non steam app...then set laounch option to --no-sandbox ....since i did that i can run r2modman and alsto start modded now works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Minor issue
Projects
None yet
Development

No branches or pull requests

9 participants