mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3739] Steam doesn't work with symlinked steamfolder #2361
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#2361
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 @TheOneric on GitHub (Nov 11, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3739
Some Manjaro update(not sure if firejail or steam update caused this) between a few weeks ago and now, steam stopped working with firejail and my custom steam locations (via symlink). The symlink targets are on another ext4-partition and are owned by the same user and group running steam.
On startup I get
As the
~/.steamfolder is a symlink and I guess it might make sense to require the symlink target to be whitelisted, I now atempted to whitelist the symlinked folders in/usr/games/Games-{HDD,SSD}(details at the end together with debug output) in /etc/firejail/steam.local, but now this fails with:No profile and disabling firejail
--no-profiledoesn't change anything.Reproduce
Steps to reproduce the behavior:
firejail steam,firejail --noprofile steamor to work around issues with controllers and #3267 (probably no longer needed)while
~/.steamis a symlink to/usr/games/Games-SSD/Steam-Runtime.Environment
firejail --versionlists all but SELinux as enabledChecklist
https://github.com/netblue30/firejail/issues/1139)LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 PROGRAMto get english error-messages.debug output
OUTPUT OF `firejail --debug steam`With this in /etc/firejail/steam.local :
firejail --debug steamoutputs:@ghost commented on GitHub (Nov 11, 2020):
Have you tried making that path read-write yet? Something like
read-write /usr/gamesmight do...@rusty-snake commented on GitHub (Nov 12, 2020):
/usr/gamesmust be owned by $USER do to this.@TheOneric commented on GitHub (Nov 12, 2020):
Thanks for your replies.
usr/gamesis not owned by $USER, butusr/games/Games-{HDD,SSD}are. After addingto steam.local it now seems to work at first glance.
If you don't mind me asking, what's the difference between whitelisting and read-write? I was under the impression noblackist+whitelist would be the correct and sufficient approach to make locations fully accessible to an app. Are there any side-effect with
read-writeonly, like the app can write to this location but changes will be erased after restart? The manpages mentioned only changes to whitelisted paths being permanent…And what makes
/usr/games/Games-HDD/xyzan invalid whitelist-path even though bothusr/games/Games-HDDandxyzare owned by $USER, while eg~/.config/xyzis a valid whitelist-path?@rusty-snake commented on GitHub (Nov 12, 2020):
whitelist:whitelist ${HOME}/fooenables whitelisting in $HOME and makes ~/foo appear in the sandboxread-only/read-write: control ro/rw of a file/dirnoblacklist: ignore any laterblacklistfor that path. This means it is only necessary if there such a blacklistwhitelist: is only necessary if whitelisting for that location is enabledThe issues here is that only $HOME and /tmp are rw inside the sandbox by default.
Changes are not permanent if
overlay-tmpfsis usedtmpfsis usedprivate-homeis usedprivateis used (private ~/foobaris another thing)... if whitelisting is used for that location
whitelisting is only supported in $HOME, /run/user/$UID, /etc, /var, /usr/share, and a few more see the manpage.
@TheOneric commented on GitHub (Nov 12, 2020):
Thank you very much for this explanation!