SLR creates a var folder that ignores ACL

[Damglador]

Your system information

• Steam Runtime Version: 4
• Distribution (e.g. Ubuntu 18.04):
• Link to your full system information: https://gist.github.com/Damglador/656ea0fa32b425ca06656ebbe58e19a3
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton-GE/Experimental
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   1.0.20260618.246542                     # Overall version number
LD_LIBRARY_PATH 1.0.20260618.246542     scout   1.0.20260618.246542     # steam-runtime/
scripts 0.20260618.0                    # from steam-runtime-tools

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   2.0.20260805.254767                     # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64   0.20260805.0
scripts 0.20260805.0                    # from steam-runtime-tools
soldier 2.0.20260805.254767     soldier 2.0.20260805.254767     # soldier_platform_2.0.20260805.254767/

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   3.0.20260805.254768                     # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64   0.20260805.0
scripts 0.20260805.0                    # from steam-runtime-tools
sniper  3.0.20260805.254768     sniper  3.0.20260805.254768     # sniper_platform_3.0.20260805.254768/

• What versions are listed in steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   4.0.20260805.254769                     # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64   0.20260805.0
scripts 0.20260805.0                    # from steam-runtime-tools
steamrt4        4.0.20260805.254769     steamrt4        4.0.20260805.254769     # steamrt4_platform_4.0.20260805.254769/

Please describe your issue in as much detail as possible:

Folders created in a directory with default ACL should follow that f ACL instead of ignoring it and setting permissions to 700, or the folder shouldn't be created in external library in the first place, as it breaks sharing that library with other users on the system.

┌─[damglador@DamgladorPC][~/.steam/SteamLibrary/steamapps/common/SteamLinuxRuntime_4]
└% getfacl .
# file: .
# owner: damglador
# group: games
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

┌─[damglador@DamgladorPC][~/.steam/SteamLibrary/steamapps/common/SteamLinuxRuntime_4]
└% getfacl var
# file: var
# owner: damglador
# group: games
# flags: -s-
user::rwx
group::--- <- This should be rwx
other::---
default:user::rwx
default:group::rwx
default:other::r-x

SLR Soldier and Sniper do the same thing

Steps for reproducing this issue:

1. setfacl -R -d -m u::rwX,g::rwX,o::rX steamapps/common/SteamLinuxRuntime_4
2. rm -r steamapps/common/SteamLinuxRuntime_4/var
3. Run a game with Proton for SLR4 to recreate the var folder
4. getfacl steamapps/common/SteamLinuxRuntime_4/var

[smcv]

SLR is not designed to be shared between multiple Unix uids, and neither are Steam libraries in general, as far as I'm aware. Proton prefixes (in compatdata) also need to be owned by the current user.

If it was technically feasible, SLR would avoid writing to the Steam Library at all (and only write to /tmp or ~/.cache, instead), but var/tmp-* needs to be on the same filesystem (same drive) as SLR itself. This is because SLR needs to set up modified versions of the runtime to accommodate your system's graphics driver stack, and to avoid wasting lots of disk space and I/O bandwidth, it does this using hard links. Hard links only work within a single filesystem, so they have to be on the same filesystem as SLR, and the easiest way to guarantee that on all systems is to put them in a subdirectory of SLR. Creating these hard-links when multiple uids are involved is also unlikely to work correctly, especially if the kernel is configured with hard-link restrictions (which are a form of security hardening).

sharing that library with other users on the system

If other users can write to your Steam library, and you run code from that Steam library, then those users can run arbitrary code as you (privilege elevation, removing the security boundary that normally exists between users). Check that this is really what you want!

By default, SLR sets cautious permissions rather than leaving access wide-open. It can't solve pre-existing security problems, but it tries not to at least not create new security problems that it would be blamed for.

var folder of SLR 3 followed ACL from what I can tell

There is no difference between SLR 3 and SLR 4 in this area. SLR 4 has newer libraries inside the container, but the container framework that's used to set it up is identical.

One way you might be able to work around this, at your own risk, would be to delete var and re-create it with the permissions and ACLs that you want it to have (or leave it in place, but set permissions and ACLs on it). Perhaps you already did this for SLR 3, and then forgot you had done so?

Or, you could install SLR into a Steam library used only by your own uid (the one in ~/.local/share/Steam/steamapps would be convenient), and continue to use games in a library writeable by multiple users (again at your own risk).

[Damglador]

Yes, Proton is also a pain in the ass for this, there's an insanely overcomplicated workaround I had to figure out: https://damglador.com/guides/shared-steam-library-on-linux

Check that this is really what you want!

Yes, I do not want to buy another 1TB drive for the second user and so on. That's insanity. And sharing one Unix account for all users on a family PC is even worse.

you could install SLR into a Steam library used only by your own uid

That is what I ended up doing, but unless I do that manually, Steam will install it in the default library, which is obviously the external shared 1TB drive. In case it isn't supposed to be shared, that shouldn't happen. Though installing 2,2GiB combined of runtimes for each user is suboptimal.