mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4366] Steam Proton (Experimental) doesn't work, even under an empty profile #2636
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2636
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @matthew-cline on GitHub (Jun 20, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4366
While using Steam with experimental Proton to try to run the Windows game Dig or Die the game immediately exits after hitting "play", even I use an entirely empty profile for Steam. Running Steam directly/natively there's no problem. Using
PROTON_LOG=1doesn't cause a log file to be generated, so Proton seems to be crashing/exiting before it even gets a chance to create the log file. Even withSTEAM_LINUX_RUNTIME_LOG=1andSTEAM_LINUX_RUNTIME_VERBOSE=1set neither the stdout/stderr of the Steam client nor any of the Steam log files shows any errors or warnings when attempting to launch the game.I tried running Steam under strace to see what the problem might be, but Steam crashes under strace, even if run outside of the Firejail sandbox.
Environment
Distro: Fedora 34
Steam: built Jun 8 2021, version 1623193086
firejail --version
@SkewedZeppelin commented on GitHub (Jun 20, 2021):
Likely related:
https://github.com/flathub/com.valvesoftware.Steam/issues/642
https://github.com/flatpak/flatpak/issues/3797
@rusty-snake commented on GitHub (Jun 20, 2021):
Is anything in the syslog? Does it work with noprofile.profile?
@matthew-cline commented on GitHub (Jun 20, 2021):
Same behavior with
noprofile.profile. The only thing that the the syslog shows is that it's uploading a MiniDump crash log (something I'd missed when looking at the client's stdout), so there is some sort of crash going on.@matthew-cline commented on GitHub (Jun 20, 2021):
I tried running Steam outside of Firejail but with a private PID namespace (
unshare -p), and while that doesn't exactly duplicate the problem it does cause things to freeze at the "launching game" popup stage. So Firejail creating a private PID namespace probably has something to do with it.@rusty-snake commented on GitHub (Aug 4, 2021):
still an issue?
@Rult commented on GitHub (Aug 20, 2021):
Still an issue. It also occurs for Proton 6.3-5 and 5.13-6.
Distro: Manjaro KDE (kernel 5.10.59-1)
firejail version 0.9.66
Output log example (ShareX under Proton Experimental)
Steam's bubblewrap doesn't seem to work with firejail.
@SkewedZeppelin commented on GitHub (Aug 20, 2021):
Use flatseal to further restrict access, start Steam, set "Proton (community build)" as default
@TheOneric commented on GitHub (Nov 9, 2021):
Proton 5.13-6, 6.3-7 and current (2021-11-09) Experimental work for me if running with
--noprofile. With the default profile (+my local additions for additional library folders) it fails with the following message in the terminal output:Proton ≤ 5.0 continues to work with the default profile.
firejail --version
@TheOneric commented on GitHub (Nov 10, 2021):
Proton 5.13-6 and 6.3-7 appear to work for me if
--ignore=seccompis added to the dfeault profile.Ofc, ideally we'd like to only allow the syscalls actually needed for Proton+bubblewrap, but unfortunately I do not know what those are or how to find this out. If I can help by testing configurations, let me know.
@rusty-snake commented on GitHub (Nov 10, 2021):
9a81078ddb/etc/templates/syscalls.txt (L89-L112)@TheOneric commented on GitHub (Nov 10, 2021):
I tried to follow the instructions, but no related messages show up in journalctl when running
firejail --seccomp-error-action=log /usr/bin/steam. I ranjournalctl --grep=SECCOMP --followas the same user as steam, as root and (as root) without--grep=SECCOMP, but no related messages showed up.While running steam with
--seccomp-error-action=logthe games using Proton > 5.0 did start successfully, when started without this flag they did not.@kmk3 commented on GitHub (Nov 10, 2021):
FWIW, 5.13+ never worked for me.
I assume it's either because it now requires bwrap and that it is incompatible
with firejail and/or because the new runtime requires allowing unprivileged
user ns for steam. I haven't looked too much into it and didn't try disabling
things in the profile though.
5.0-10 and earlier still work.
Environment: firejail-git on Artix Linux.
@rusty-snake commented on GitHub (Nov 11, 2021):
@TheOneric does
firejail --seccomp=openat --seccomp-error-action=log cat /etc/profileshow-up in journalctl (i.e. is this likely a 32 bit seccomp issues or a configuration of your system)?@TheOneric commented on GitHub (Nov 11, 2021):
Hmmm, this too does not cause any seccomp related messages to show up in journalctl. Grepping through
sudo journalctl --allalso doesn't show any messages other than a messages during boot and the invokation offirejailorjournalctlwith a seccomp paramter.Can I somehow tell firejail to log seccomp-errors to a file, stdout or stderr instead?
@rusty-snake commented on GitHub (Nov 11, 2021):
This logging isn't done by firejail, it is done by your kernel. Which distro do you use?
@TheOneric commented on GitHub (Nov 11, 2021):
openSUSE Tumbleweed
@TheOneric commented on GitHub (Dec 3, 2021):
Since #4686 mentioned the seccomp lines showing up in Fedora, I tried to recompile the prisitine kernel.org sources dor 5.15.6 with a matching config from fedora, but this failed to boot with openSUSE just looping some failure messages regarding CUPS scheduler. If it's known which kernel configurations need to be changed to get the seccomp logs, I could try to recompile a openSUSE kernel with the nedded config change to get more info.
@rusty-snake commented on GitHub (Dec 4, 2021):
What audit config does openSUSE use?
Fedora:
@TheOneric commented on GitHub (Dec 4, 2021):
Seems to be the same:
@remyabel2 commented on GitHub (Dec 30, 2021):
The syscall is 165 (mount). Which matches up with the error I get:
pressure-vessel-wrap[4]: E: Diagnostic output:
bwrap: Failed to make / slave: Operation not permitted
Note that I'm running proton manually which is why I'm able to see this diagnostic, likely it's swallowed by steam if you're running it that way.
@TheOneric commented on GitHub (Jan 8, 2022):
What did you add to your local profile to make it work?
If I add either only the first or both of the following lines, Proton past 5.0 still doesn't work with steam (same error as before and your post).
@remyabel2 commented on GitHub (Jan 8, 2022):
@TheOneric Sorry for being vague, I didn't actually manage to get it to work, was just adding additional info to the post based on the commands discussed.
Additional info:
There are basically three ways of running proton. Within steam (and the runtime), without steam and the runtime and through protontricks (which can utilize the runtime). On my machine, using
--noprofileworks for the second option. You will get a diagnostic about something crashing (but everything otherwise works fine) that's linked to--protocol=unix,inet,inet6from the default profile.@ghost commented on GitHub (Jan 8, 2022):
@remyabel2 Please be aware that using the
--noprofileoption isn't safe for daily use: it offers zero protection!. It's more of a test option to check if firejail is able to sandbox an app.@remyabel2 commented on GitHub (Jan 8, 2022):
Yes I'm aware. I was addressing the fact that earlier it mentioned that
noprofiledoes not work. It does now, or maybe it's because they were trying to run it with Steam. Either way, running this out of steam works aside from the one issue I mentioned earlier:Attempting to run it with Steam has issues because of the containerization (discussed elsewhere and in another issue).
I may be leaving information out because of the permutations mentioned earlier/fuzzy memory but i think I covered everything.
@TheOneric commented on GitHub (Jan 8, 2022):
As I mentioned previously, using
--ignore=seccompis already sufficient to get Proton past 5.0 working from within Steam. However, since the instructions to figure out what exactly failes do not work for me on OpenSUSE (they are confirmed to work on Fedora though), we do not know which syscall(s) need to be whitelisted. It does not appear to be (only) themount-call you mentioned — unless I didn't whitelist it correctly.Do I understand you correctly, that if run from outside Steam, you do not need to change anything about the default profile, not even whitelist
mountto get Proton >5.0 working? Also, if you do have the option to run Proton from Steam and it doesn't bother you too much, could you perhaps try if the instructions work for you and report the result? (Also see here for a quick test of seccomp-logging)@remyabel2 commented on GitHub (Jan 8, 2022):
I do not use OpenSUSE, I use Fedora.
Steam runs proton inside a container with the steam runtime and will attempt to mount parts of the filesystem. If you run proton outside of steam, you are not using containerization or the runtime (it will instead use system libs). You can emulate Steam's behavior with protontrick's bwrap feature.
I already followed those instructions, that's how I got the syscall for mount on my machine (it likely will be different for other people's machines.) However, I don't really recommend using Firejail and Steam/Proton at the same time, because Valve tends to change the implementation details every now and then and the profile will silently break until it's updated. I'm not qualified to speak on whether or not double sandboxing is worth it.
@TheOneric commented on GitHub (Feb 28, 2022):
I installed Fedora Workstation in a VM and followed the documented Fedora procedure with a lightweight game. The seccomp logs there show up in journalctl as expected. Here are the results:
teeing the journalctl output to a file and filtering the syscalls like thisawk '/^#/ {next} 1 {arch=""; syscall=""; for(i = 0; i < NF; ++i) {if($i ~ /^arch=/) arch=$i; else if($i ~ /^syscall=/) syscall=$i; } if (arch && syscall) print arch" "syscall;}' steam-seccomp.log | sort | uniq -cyields the following result:Adding
seccomp !mount,!name_to_handle_at,!pivot_root,!umount2to/etc/firejail/steam.localdid not result in this working and if run with logging we can see the very same syscalls as before being still blocked (@rusty-snake: is this expected?). But instead altering theseccomp !ptraceline in the defaultsteam-profileto the below allows Proton 7.0, Proton 6.3 — and presumably also Proton 5.13 — to work, fixing the issue.@rusty-snake commented on GitHub (Feb 28, 2022):
IIRC the accumulated in the past.