why do games running in proton have access to the entire linux filesystem via Z:?

[craig-sanders]

Proton (all versions) creates a symlink to the machine's root / directory as .../pfx/dosdevices/Z:

Why? This allows any game running in steam to trawl through my entire filesystem - with write access to any file where unix perms allow it.

I don't want steam games having access to even my home directory. They don't need it, there's nothing in there that they have any legitimate need to access or modify.

All that a game running in steam needs is access to the proton pfx dir (C:), the game's own install directories (and possibly the entire set of steam library directories) and a shared directory for common config files or data (currently it uses ~/.local/share/ for this. It shouldn't - it should use a directory under ~/.steam/ instead).

This could be achieved by setting up an S: symlink for steam's root dir (e.g. ~/.steam), G: for the game's install directory, and drive letters for each steam library (starting from, say L:). Alternatively, steam could have a symlink farm pointing to each steam library.

e.g. I have 5 steam libraries on my system (all of them are on ZFS datasets, some HD, some SSD):

Steam Library	Notes
1. /var/games/steam/steam	~/.steam/ is a symlink to /var/games/steam/
2. /var/games/steam1	linux native games on HD
3. /var/games/steam2	windows games on HD
4. /var/games/ssd	windows games on SSD
5. /var/games/ssd-linux	linux games on SSD

The datasets for windows games are set to be case-insensitive (like FAT or NTFS because windows devs are often sloppy about upper/lower case, using multiple different capitalisations for the same file/dir in the same game).

(Most games stay on the HD, but I occasionally move some games to the ssd libraries if i want to ensure maximum disk I/O performance)

These could be symlinked to L:, M:, N:, O:, and P: in pfs/dosdevices. Or they could be symlinks inside another directory (e.g. ~/.steam/steamlibraries or similar), with that directory being L: in .../pfx/dosdevices

Doing this, or something like it, would prevent steam games from accessing files and data that they have NO BUSINESS even attempting to open. Running a game is NOT permission to trawl or modify my data, nor is it willingness to allow a bug in a game to overwrite or corrupt my data.

I don't really care if a game bug causes it to trash itself or some other game or even steam - I can always validate and re-download....but I have no way of even knowing if a game overwrites data it shouldn't have even been able to access, which means that by the time I notice, if I ever do, even the snapshots and backups of my original, un-corrupted data may have expired.

In short, steam/proton should self-isolate as much as possible.

BTW, I know I could run steam in docker or some other container system (a VM is no good because graphics performance would suck without PCI pass-through of a dedicated graphics card). And containers have problems of their own. Anyway, I shouldn't have to. Steam/proton should not enable access to stuff not needed by the game - which is part of the point of running each game in its own dedicated wine/proton prefix, or would be if the Z: drive didn't give access to everything.

[junaru]

Disagree, wine is not an emulator that keeps applications isolated from the host, its a compatibility layer and thus expected to have all the permissions the user has. Its not uncommon to have applications in directories outside of prefixes be it for testing purposes or for example using executables directly from your Windows drive.

Running a game is NOT permission to trawl or modify my data, nor is it willingness to allow a bug in a game to overwrite or corrupt my data.

It is, in both Windows and *nix land. You roll the dice every time you launch any application.

Steam/proton should not enable access to stuff not needed by the game - which is part of the point of running each game in its own dedicated wine/proton prefix.

The recommendation to use multiple prefixes comes form the fact wine is not perfect and a single prefix will eventually break in a non reproducible way given enough applications modify it. Although orders of magnitude less this even happens in Windows and when it does you format you system drive and leave the data drives alone.

Z: is just another data drive.

[craig-sanders]

If you don't have anything useful to say, why bother responding? Is it just to be an apologist for spyware devs? To give a performative dance celebrating software and corporations that want to own you?

Disagree, wine is not an emulator that keeps applications isolated from the host, its a compatibility layer and thus expected to have all the permissions the user has.

You must be proud to have the Master Of The Bleeding Obvious achievement.

WINE's (and thus Proton's) isolation is far from perfect, but it's not completely useless. The problem is that proton currently sets up every prefix access so that it has access to the entire filesystem (via the ..../pfx/dosdevices/Z: symlink to /), subject only to file/dir permissions (so they can read & write all files/directories owned by my uid including stuff mounted from my fileserver, and to files/dirs writable by any of the gids my uid is a member of, plus read-only access to lots of other stuff, including files belonging to other user accounts on this system).

It should not do that. It should give minimal access, only what is absolutely required. I shouldn't have to trust that a game won't abuse any access they have, or that it won't have a bug that accidentally erases my home dir - they shouldn't have access to more than they need to begin with.

I'm not expecting perfection from Steam or from Proton. I'm expecting at least a decent minimal attempt at Harm/Risk Minimisation. Z: -> / is Harm/Risk Maximisation.

Its not uncommon to have applications in directories outside of prefixes be it for testing purposes or for example using executables directly from your Windows drive.

So? Special cases can and should be handled differently. If you need to give a particular game access to some directories or files then copy or symlink them (and only them) to wherever they're needed. The default, however, should be that games should have access to only what they need and not a single byte more.

Running a game is NOT permission to trawl or modify my data, nor is it willingness to allow a bug in a game to overwrite or corrupt my data.

It is, in both Windows and *nix land. You roll the dice every time you launch any application.

IT IS NOT. I do not give any program, game or otherwise, to steal or otherwise misuse my data.

The fact that some programs (very few on linux, many on windows) abuse the access they have to do things they shouldn't is NO REASON to accept that, and no reason to make it easy for abuse to occur.

Your comment is no better than saying "you can get mugged or worse by anyone, so just accept it. It's normal and there's nothing you can do about it anyway".

Steam/proton should not enable access to stuff not needed by the game - which is part of the point of running each game in its own dedicated wine/proton prefix.

The recommendation to use multiple prefixes comes form the fact wine is not perfect and a single prefix will eventually break in a non reproducible way given enough applications modify it.

This is a Proton bug report, not a WINE bug report. Proton is based on WINE, but it's not exactly the same - it's wine + valve's changes + integration into the steam client so that all the setup is done automatically.

That auto-setup is a huge win - my old method of just cloning a "base" steam WINE prefix for each game was a PITA, even when mostly-automated via some shell and perl scripts I wrote. Each new prefix had to run its own (windows) steam client and log in to steam, a process which involved authenticating every new prefix by clicking on the link in the email that steam sends you when you login from a new device....because each new WINE (not proton) prefix is seen as a new device by steam because it's running its own instance of steam. With Proton, that's not an issue - there's one login with one steam client, and it manages all the proton prefixes for all the windows games in the library.

But you are missing the point entirely. This bug report is not about whether games should be isolated from each other. It's about whether they should, by default, have access to the entire filesystem. They don't need it, so they shouldn't have it. Since steam, and everything it runs, is running under my UID, the only way to prevent games from accessing things they shouldn't is to limit what they can actually see - starting with not creating the Z: drive symlink to /.

Although orders of magnitude less this even happens in Windows and when it does you format you system drive and leave the data drives alone.

Avoiding insane crap like that is one of the reasons I use Linux instead of Windows. I don't have the Windows user's typical Stockholm Syndrome, and I don't want to acquire it. My computer belongs to ME, not to Microsoft or to Valve or to some game studio or publisher, or to anyone else. It belongs to ME, and I decide what is allowed to happen on it.

Windows machines don't matter. They're toys, that should never be trusted with anything important. Real, non-toy, machines do matter.

After several years of running steam in wine, i eventually built a win7 machine from spare parts (after upgrading my main machine), partly so I could play the games I bought that just didn't work in WINE. I didn't really care about what happened to that machine - I never used it for anything but playing steam games.

If it got messed up by game dev incompetence (or malice), or got infected by some malware, I could just blow it away and rebuild it - there was nothing on it that couldn't be downloaded again (even the setting and save files for most games were synced to the steam cloud), and there was no personal data on it that could be stolen.

I didn't even buy games on it, I bought them in a browser on Linux, then downloaded them with the steam client on windows - there's no way I'll ever enter my credit card number or paypal login or whatever anywhere on a Windows machine. Windows can't be trusted for anything important and isn't suitable for handling even slightly sensitive data.

Now, though, because Proton has got so good, I've switched back to running games only in linux - I haven't even turned on the win7 box since early this year, probably won't ever do so again, have even taken the gtx 1060 out of it and put it in my linux box to replace the gtx 970 - and I do care about what happens to it and about the data that proprietary programs might try to steal from my personal files. Just blowing it away and rebuilding is NOT an option, I use my machine for a lot more than just gaming.

Z: is just another data drive.

and if proton was set up correctly for each game, it wouldn't be giving access to the entire filesystem. Setting it up like that is just lazy.

Games running in steam do not need access to, for example, my ~/.mozilla/ or ~/.config/chromium directories and all the browser profiles and their bookmarks and stored passwords and cache data.

They don't need access to my ~/mail/ directory and the 25+ years worth of mail archives that it contains. They don't need access to my ~/doc/ directory, my calendar, my address book, or my ~/git/ directory either. Or my ~/.gpg/ or ~/.ssh/ directories.

They don't need access to anything except Steam itself, the game's own files, and maybe to other games in the steam library (e.g. for games like Mass Effect 2 which could make use of your save file from Mass Effect 1).

[kisak-valve]

Hello @craig-sanders, Proton (and wine) needs access to the wine prefix to set itself up in the first place and run in general, including those symlinks and access to the configuration doesn't change afterwards. You're asking for weak obfuscation here and an intentionally malicious piece of software could just as easily add a drive mapping later. While there is some merit in your request, you'll want to take stronger measures to isolate Steam as well as all untrusted applications if that is a security requirement for your system.

Wine does not provide the level of discrete access control you're asking for and we shouldn't invest time in refining a fake security barrier.

As for why Z: is used, my understanding is that the Steam client hands off an absolute path to the executable, and this is the easiest way to align the windows and linux folder expectations.

[Saancreed]

Welp, looks like Kisak already answered, but I'll try to explain a few things anyway.

why do games running in proton have access to the entire linux filesystem via Z:?

Because that's how Wine always did it, and Proton has little reason to change it. Wine is not a sandbox and afaik the purpose of Proton is to integrate multiple projects, like Wine and DXVK, into the Steam client to simplify running Windows games on Linux. Sandboxing them is just out of scope of both of these projects.

Steam/proton should not enable access to stuff not needed by the game - which is part of the point of running each game in its own dedicated wine/proton prefix

No, it doesn't explicitly enable such access, it only doesn't disable it. The point of running each game in a separate prefix is mostly to ensure that game–specific hacks don't break other games.

My computer belongs to ME, not to Microsoft or to Valve or to some game studio or publisher, or to anyone else. It belongs to ME, and I decide what is allowed to happen on it.

Cool. So, because you are responsible for security of your data, it is on you to ensure it is actually secure.

Most Linux distros don't deal with stuff like this: when I pacman -S firefox, it can read my entire home directory. When I pacman -S discord, it can do the same. When I pacman -S steam, it obviously can do so too, and so can all games I install with it, both native Linux and Windows ones.

I know I could run steam in docker or some other container system

Nah, containers are not the right tool for the job here. Have you considered using Firejail to isolate the entire Steam client? It shouldn't have any performance penalties and I don't see why it wouldn't handle your use case.

[craig-sanders]

You can spare me the patronising "explanation"...but do tell me how a windows program running under wine can access any part of the filesystem that they haven't been given access to by a drive letter symlink.

If .../dosdevices/Z: (or whatever) only points to some sub-directory somewhere (and NOT to the root dir), how is the windows program going to get access to files outside of that subdirectory? It has no windows drive letter or path to anything else.

Sure, there may be some zero-day exploit against wine or proton that could be used (security is not one of WINE's biggest priorities), but game programs are opportunistic snoopers at worst (most of them aren't even that), not maliciously trying to exploit bugs in wine. If they can access data because it's easily available on what looks a normal windows drive letter, they might do so - but they're not going to be trying to hack the system to get access to the linux system.

And I would hazard a guess that NONE of them are actively and maliciously trying to corrupt data - but some do exactly that by accident because they're buggy. Not giving windows programs, buggy or not, access to more than they need will prevent them from accessing or overwriting files that they shouldn't.

(there's some irony in this, BTW - Valve's own steam.sh wrapper script for launching the steam client had a bug which could, in certain circumstances, run rm -rf / - i.e. delete every file & directory in every directory that the user had write access to - it actually ran rm -rf "$STEAMROOT/"* but there were several circumstances where the STEAMROOT env var could be empty. See https://github.com/ValveSoftware/steam-for-linux/issues/3671 and also note that this wasn't the only issue reported here relating to improper or dangerous use of variables in the script, That's not malice, that's just carelessness).

From the winehq.com link you posted:

Note that the winetricks sandbox verb merely removes the desktop integration and Z: drive symlinks and is not a true sandbox. It protects against errors rather than malice. It's useful for, e.g., keeping games from saving their settings in random subdirectories of your home directory

And that's good enough. It's about all that can be expected from wine or proton. Any more than that requires running steam in some kind of container or, as suggested by winehq, using apparmor or selinux or a VM.

And, you know, that's entirely consistent with what I said when I posted this issue.

Because that's how Wine always did it, and Proton has little reason to change it.

Proton has very good reasons to change it. It prevents any one of the thousands of games from accessing or overwriting data that they have no need to access. It won't stop the truly determined and malicious, but it will stop accidental corruption and opportunistic snooping.

When running WINE myself, I can delete any symlinks I don't want under dosdevices/ - d::, e::, and z: for example, and set things up how I want them.

I can't do that with Proton because it passes the absolute path of the directory and executable etc to wine. It doesn't need to and shouldn't do that. It should make, for example, a G: drive letter pointing to the game's install path, and use paths relative to G: (e.g. instruct wine to run G:\game.exe, not Z:\var\games\steam2\steamapps\common\gamedir\game.exe). I can delete the symlink manually, but then the game won't run. I can't even replace the Z: symlink with one pointing directly at the game's dir because the executable's pathname beneath Z: would be wrong.

The only reason for proton to do this is a lazy reliance on defaults. And as I showed in my examples in my initial post, it's not hard at all to come up with a better scheme than symlinking pfx/dosdevices/Z: to \ - e.g. G: for the game, S: for steam itself, and L: for steam game libraries (this could also contain a subdirectory for config data and savefiles, instead of using ~/ or ~/.local/ or whatever and having that stuff strewn all over the home dir). These work (or they could, if implemented), and they're easy to remember.

(btw, i've modified my own version of protontricks so that it can create exactly that G: symlink. Also hacked it so that I can get it to run, e.g., cmd.exe with the game's correct version of proton instead of just running winetricks. This allows me to change to "drive" G: rather than z:\stupidly\long\path\to\a\game in cmd.exe without tab-completion and then run whatever I need in the exact same proton runtime context of that particular game - installing a mod manager, for example....the same kind of stuff i used to do years ago when running steam in wine. Hacking on protontricks is what made me realise that proton creates this Z: symlink pointing to /, and that it is unsafe and un-neccessary).

Steam/proton should not enable access to stuff not needed by the game - which is part of the point of running each game in its own dedicated wine/proton prefix

No, it doesn't explicitly enable such access, it only doesn't disable it. The point of running each game in a separate prefix is mostly to ensure that game–specific hacks don't break other games.

It does explicitly enable such access by creating the Z: symlink instead of symlinks giving access to only what is needed and appropriate.

Cool. So, because you are responsible for security of your data, it is on you to ensure it is actually secure.

Yes, I am.

And that responsibility includes raising bug reports for things that are both a) extremely obvious and b) equally obviously have never even been considered. Just accepting default behaviour isn't always a good idea (hint: it usually isn't).

As I mentioned above, I can not change how Proton works, and I certainly can not change how steam passes the executable pathname to WINE. That can only be done by Valve.

Most Linux distros don't deal with stuff like this: when I pacman -S firefox, it can read my entire home directory. When I pacman -S discord, it can do the same. When I pacman -S steam, it obviously can do so too, and so can all games I install with it, both native Linux and Windows ones.

You know that there's a huge difference in the level of trust given to distro developers versus the trust given to developers of random windows games, right? At least for the distros with competent and experienced people. And there's a difference between distro packages and games installed by the steam client. Most distros have policy and procedures to make sure that only trusted and verified people can upload packages, and to deal with security issues caused by either accident or malice.

I, for example, trust my fellow debian developers a hell of a lot more than I trust either Valve or, worse, some random windows game programmer....or the company that's probably over-working and under-paying them. A company that might decide it has a financial incentive to do evil and unauthorised stuff like snoop in my personal data to build a profile of me that they can sell to advertising scum or list brokers and other vermin....it's not as if game publishers haven't done that kind of thing many times already.

I know I could run steam in docker or some other container system

Nah, containers are not the right tool for the job here. Have you considered using Firejail [...]

What do you think Firejail is? It's a container system - fairly lightweight compared to docker or lxc, and aimed at end-users rather than systems administrators, but it uses exactly the same namespaces mechanism provided by the linux kernel to isolate programs from the rest of the system

[craig-sanders]

Hello @craig-sanders, Proton (and wine) needs access to the wine prefix to set itself up in the first place and run in general,

Of course. That's not what my issue is about. The issue is that windows program running under that prefix are given access to the entire linux filesystem, when they don't need it and shouldn't have it.

including those symlinks and access to the configuration doesn't change afterwards.

no. it obviously needs some dosdevices symlinks, but it doesn't need that z: -> / symlink. It doesn't need anywhere near that level of access to the host filesystem.

Windows games can snoop as much as they like in pfx/drive_c or even in steam library directories - I don't really care - but I shouldn't be obliged to give read OR write access to my personal files in my home directory or to anything else in my machine's filesystem or mounted from my file server.

You're asking for weak obfuscation here

No, i'm asking for minimal protection against buggy (or overly intrusive) windows apps.

and an intentionally malicious piece of software could just as easily add a drive mapping later.

1. i'm not expecting proton to protect against intentionally malicious software (i do, however, expect Valve to remove such software from their library as soon as they're aware of it - and to notify their customers who have installed it).

2. How could such software create that symlink? It doesn't have access to the ../pfx/ directory itself, or to ../pfs/dosdevices/. It only has access to ../pfx/drive_c/ and the directories pointed to by the drive letter symlinks in .../pfx/dosdevices (which wine/proton present to the windows environment as normal-looking drive letters).

While there is some merit in your request, you'll want to take stronger measures to isolate Steam as well as all untrusted applications if that is a security requirement for your system.

Perhaps so, but this is something that valve could easily implement in proton to protect their customers who aren't capable of running steam in a container or protecting themselves. All it takes is just NOT doing the obviously insecure thing and making some minimal effort to do things a bit more securely.

Software should be written to act defensively wherever possible. And that's especially true for software whose main purpose is, like the steam client and proton, to execute third party code.

Wine does not provide the level of discrete access control you're asking for and we shouldn't invest time in refining a fake security barrier.

It's not a fake security barrier. It's not perfect or "high security" but it is effective against bugs and opportunistic snooping. It's effective unless there's some bug in wine or proton that is being actively exploited to gain access to the file system outside of the drive letters in pfs/dosdevices/

Also, proton isn't wine. It's Valve's fork of wine.

and yes, Valve should make at least a minimal effort to implement some kind of security. Especially when it is trivially easy to do so. Fixing this is not some huge software-engineering effort.

It's removing the code that creates the Z: symlink, and replacing it with a few lines to use the data available in the steam client to create 3 symlinks in a prefix that give access to ONLY the minimum data needed by a game - steam itself, the game's install dir, and a shared directory for configs and save files (instead of ~/.local/share/).

an even better solution would be for steam to fork each proton instance in its own namespace (using the mnt, pid, probably ipc, and maybe net namespaces with access to only the required directories - the kernel provides that capability in every version of linux since at least 2008 with kernel 3.8 (namespaces were first introduced with v 2.4.19 in 2002. The cgroup namespace was added in 2016 with kernel 4.6). But that would be a lot more work, not a quick fix.

As for why Z: is used,

the drive letter is unimportant, it could be any letter and the problem would be the same.

my understanding is that the Steam client hands off an absolute path to the executable, and this is the easiest way to align the windows and linux folder expectations.

yes, that's the problem. easiest. not the best, or the only way.

However, it's no more difficult to create drive letter symlinks that provide only the minimum required access to files actually needed by the game.

All it takes is a little thought, and even less effort. All the information required to set up the necessary symlinks is available within steam. All it has to do is make use of it.

And, no, i'm not saying "drop everything and do this now". It's not ultra-high priority. I'm saying that this is an important issue which is easily solved and it should be, at the very least, on some TODO list for someone to investigate (and hopefully implement) when they get time. i.e. this issue shouldn't be closed.

[Saancreed]

patronising

Whoops, I'm sorry, I didn't mean to.

do tell me how a windows program running under wine can access any part of the filesystem that they haven't been given access to by a drive letter symlink

For example with direct syscalls, which, until very recently, were not handled at all, causing some DRM checks to fail. But considering there is some seccomp filter work going on here, maybe it won't be true in a few months from now.

Of course, that would be the case of malicious applications, against buggy and intrusive ones denying easy access to root filesystem would probably do it.

steam.sh

Yup, that was a funny one. Unfortunately, sometimes not even distro maintainers can protect users from buggy software.

It does explicitly enable such access by creating the Z: symlink instead of symlinks giving access to only what is needed and appropriate.

It's just taking the upstream defaults ¯\_(ツ)_/¯

And that responsibility includes raising bug reports for things that are both a) extremely obvious and b) equally obviously have never even been considered. Just accepting default behaviour isn't always a good idea (hint: it usually isn't).

I agree. The problem is, those defaults are fine for almost all possible use cases, and for the remaining ones, you are still able to use a separate tool. Furthermore, changing those defaults would most likely require a rework of how Proton deals with wineprefixes, which is, at least for now, unnecessary and out of scope of this project.

Isolating Windows games from Linux host simply doesn't feel like Proton's responsibility: it's there just to run those games. Even adapting pressure-vessel for this purpose would be, I believe, preferable solution to this problem.

What do you think Firejail is? It's a container system - fairly lightweight compared to docker or lxc, and aimed at end-users rather than systems administrators, but it uses exactly the same namespaces mechanism provided by the linux kernel to isolate programs from the rest of the system

Ah, I thought by 'container' you mean either exactly lxc or a software-with-all-its-dependecies-package used for easy deployments to (multiple) hosts, so my bad here. Yeah, I suppose you could call it a container system, but not everything that uses namespaces/capabilities/whatever is one of these :smile:

Still, you should be able to make use of that somehow.

[zpangwin]

I too am somewhat interested in this. But in my case, I have no desired to change the defaults proton uses... If I had been the one opening the ticket, I probalby would have requested it as an optional flag (probably in the form of an environment variable as most other proton options) and just ask if Proton could be made to use it in some limited fashion like the G:\ as being = <applicable steam library path for the game in question>

Seems like that much could potentially be added using an environment flag or some such so that the user didn't need to resort to hacking with proton script (and risking conflicts/overwrites when steam updates the currently installed proton).

ex: if user were to manually add a launch option such as PROTON_RELATIVE_SYMLINKS=1 %command% and run the game, it could have the following behavior:

1. if proton determines the pfx folder does not exist and needs to be created, it could create symlinks using a path relative to the game install dir. E.g. Let's say my game is installed at /gaming/steam/steamapps/common/Beyond Good and Evil. Default behavior would be unchanged and still create symlink "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/z:" -> "/". But with the flag, behavior would be to instead create "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/g:" -> "/gaming/steam"

2. if flag is detected, the call would pass an absolute path based from "g:/" instead of from "z:/".

That much would suffice for both allowing users to set this up without too much hassle and not having new proton updates destroy the changes.

---

But.. since this ticket is closed and realistically I suspect the powers that may be are resistant to the idea, I also have a question for anyone familiar with the innards of proton ...

If one were to manually recreate the structure of / in some subfolder along with symlinks to the relevant steam structure (similar in concept to a chroot)... something like:

If my steam library where ALL of my steam games are installed is /gaming/steam/steamapps/common (a messier but much simpler scenario than presented by OP) and I did something such as:

sudo mkdir -p -m 777 /steamroot/gaming
sudo ln -s "/gaming/steam" "/steamroot/gaming/steam"
rm "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/z:"
sudo ln -s "/steamroot" "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/z:"

I believe this would restrict the access of that game to only things under my "gaming/steam" folder. I believe the effects from this would be:

• In most common/trivial scenarios, a game could only "see" contents of files under my steam folder (except as noted by others above for malicious / direct / other less common stuff)
• Wine registry entries and absolute "Z:/" paths should still work because any "Z:/" paths would still resolve to the same underlying unix paths
• No code changes necessary in proton scripts / upstream since changes are purely at filesystem / symlink level
• While still requiring manual setup of the /steamroot folder and symlinks inside it, it would be reasonably trivial for me to automate remapping all of the "z:" symlinks under my compatdata folder via a bash or python script.

Would there be any other things necessary here for this to work? Wondering if I would need to similarly create symlinks to ~/.steam and/or ~/.local/share/Steam under /steamroot for it to work... not really sure what sort of access Proton allows (in the context of a windows app). One would think that from the unix side of things, Proton can just access the unix path and it wouldn't care but I haven't dug into the script much yet. Likewise, one would think that Windows stuff wouldn't be much interested in Linux paths and that mostly having the stuff under the install folder and the stuff under compatdata would be enough.

If nobody offers any input on this, I may attempt it after I finish my current playthrough and report back my findings.

[zpangwin]

For anyone else curious, I ended up revising the above to:

sudo mkdir -p -m 755 /steamroot/gaming /steamroot/home/$USER/{Documents,Downloads,Pictures,Videos,Music,.local/share}
sudo chown -R $USER:$USER /steamroot
test -d ~/.steam && ln -s ~/.steam /steamroot/home/$USER/.steam
test -d ~/.local/share/Steam && ln -s ~/.local/share/Steam /steamroot/home/$USER/.local/share/Steam
sudo ln -s "/gaming/steam" "/steamroot/gaming/steam"
rm "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/z:"
sudo ln -s "/steamroot" "/gaming/steam/steamapps/compatdata/15130/pfx/dosdevices/z:"

After trying to launch the game with the revised 'z:' symlink, I got a error MsgBox pop-up:

Title: Steam Error
Text: Application load error 3:0000065435

Seems like this ought to have potential as a workaround but I would probably need to devote more time to studying Proton's scripts to determine where it is going wrong. Perhaps someone else will stumble upon this and provide another piece of the puzzle.

For testing I was using Beyond Good and Evil with the default proton (looks like the newest one under my steamapps/common folder is 5.13-4) on Fedora 33 (Cinnamon). Used that game because I had just completed a playthrough and knew it was working without issue.

[NyaomiDEV]

I would like to add to the discussion that without access to the Z: folder, some games would stop running correctly. Take Riff Racer as an example, it needs to be fed with your own music files to work. Also, some games can be modded and Linux clients rely on the Z: symlink to negotiate a path with the game (take a look at Risk of Rain 2 and r2mod_cli / r2modman).

While sandboxing Proton games would be nice, it would also be an issue for at least those two cases. Also, it's then better to just sandbox all Steam games and not just those ones which run under Proton, IMHO.

[zpangwin]

I would like to add to the discussion that without access to the Z: folder, some games would stop running correctly. Take Riff Racer as an example, it needs to be fed with your own music files to work.

This particular use-case would actually still be possible even with drive "sandboxing" (although I don't think this is really the correct term... it is more just restricting general drive access of wine/proton sub-processes -- sandboxing has a very specific meaning in application security which IMO doesn't fit well here). To do the above under a Wine/Proton prefix that has no Z: mapping would merely require a workaround such as creating a symlink. I know because I have done something similar in the past with a wine container running Vortex and Fallout New Vegas. One of the mods I had been using was a radio mod off nexus that let you import music and I did something very similar to what you describe except that it was a subfolder where I had converted the music to the format specified by the mod rather than just pointing it at my main ~/Music folder. With Vortex, IIRC it uses hard-links and the symlink target must also reside on the same partition (I didn't test thoroughly if it was possible to use symlinks to a different partition on Linux despite their warning; I'm just paraphrasing Vortex's instructions from whenever it was I last used it).

Also, some games can be modded and Linux clients rely on the Z: symlink to negotiate a path with the game (take a look at Risk of Rain 2 and r2mod_cli / r2modman).

I believe the ask (at least in my comment above if not in OP's case as well) was to make having a Z: mapping as user choice (e.g. ENV_VAR flag/config/etc) rather than a forced decision from upstream. If implemented in such a way that would just allow the user to decide if they wanted a Z: mapping or not and shouldn't affect the defaults. But I think the way the ask was originally phrased and the tone in the arguments discussions above may have turned the maintainers off to the idea (if they weren't already against it). As I mentioned above, I hope it would still be considered as an optional feature but considering this is currently marked as a CLOSED issue, I'm not holding my breath either. I would be happy if I could just figure out a workaround to achieve this on my own without using regular wine instead of proton or having hacked proton scripts which get broken when official updates come in.

[grappas]

@kisak-valve I'm running experimental version now. It seems that some security features are already implemented. Unfortunately apps are unable to access i.e. their workshop content.

[Alexandre-Fernandez]

I totally agree with @craig-sanders, my solution is to isolate steam by running it inside a container (flatpak).

EDIT: this issue should not be closed