In the xterm ls -l ~/ should not contain the user's files from its real home directory.
Actual behaviour
The user's home directory gets mounted in the container anyway.
Additional info
If Steam is launched as PRESSURE_VESSEL_SHARE_HOME=0 steam the home isolation option works as expected.
When we launch a game _v2-entry-point gets called for the preparation steps and its environment doesn't contain the custom "Launch Options" from the game.
Only in a second moment _v2_entry_point is called again, this time to run the actual game executable, and with the "Launch Options" environment variables from the game. But at this point the container was already in place, so having PRESSURE_VESSEL_SHARE_HOME=0 here doesn't have any effect.
Designs
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Sorry, this is an unavoidable limitation of how the "session mode" used for Proton games is wired up:
Steam wants to run a setup command, like perhaps installing the MSVC runtime or something
Steam does not consider the launch options
Steam runs: /PATH/_v2-entry-point ... --verb=run -- /PATH/proton run /PATH/msvcsetup.exe
we detect that we do not have a container for this app-ID yet, and start one
we run the first setup command
Steam wants to run a second setup command, like perhaps installing DirectX
Steam does not consider the launch options
Steam runs: /PATH/_v2-entry-point ... --verb=run -- /PATH/proton run /PATH/dxsetup.exe
we reuse the container
we run the second setup command
Steam wants to run the actual game
This time Steam does consider the launch options
Steam starts by considering this command: /PATH/_v2-entry-point ... --verb=waitforexitandrun -- /PATH/proton waitforexitandrun /PATH/game.exe
if the launch options are empty, Steam runs that command directly
else if the launch options include %command%, Steam replaces %command% with that command, and runs the result
for example FOO=1 %command% --bar -> FOO=1 /PATH/_v2-entry-point ... /PATH/game.exe --bar
else Steam appends the launch options to that command, and runs the result
for example --bar -> /PATH/_v2-entry-point ... /PATH/game.exe --bar
we reuse the container
we run the part of the command that is not pressure-vessel, for example /PATH/proton waitforexitandrun /PATH/game.exe --bar
we shut down the container afterwards
(I'm slightly oversimplifying here: Steam doesn't really run msvcsetup.exe and dxsetup.exe directly, it actually runs ~/.local/share/Steam/legacycompat/iscriptevaluator.exe to tell it to run a script, and then runs that same executable again repeatedly to do IPC to the first invocation to poll whether it has finished - but the practical effect is similar.)
There is currently no explicit "start session" step: we have to start the container automatically as a side-effect of the first command that needs it.
There is also currently no explicit "end session" step: we shut down the container as a side-effect of running the actual game.
We have to start the container as soon as Steam tells us to run a setup command, but any environment variables that were set in the launch options are not available to us at that time, so we do not have the necessary information to take them into account when launching the container.
This applies to the vast majority of the environment variables that alter pressure-vessel's behaviour. I think PRESSURE_VESSEL_SHELL and PRESSURE_VESSEL_TERMINAL are the only ones that do work in a Proton game's launch options, because we special-case them to take effect after the setup commands (in the adverb) instead of during container setup - and that's because if we didn't, they'd break the setup commands!
PRESSURE_VESSEL_VERBOSE will also partially work, but not enough to be really useful (it will make pressure-vessel-adverb verbose, but by this point the container is already set up, so it's too late to make pressure-vessel-wrap equally verbose).
We cannot improve on this without changing the interface between Steam and pressure-vessel.
We cannot improve on this without changing the interface between Steam and pressure-vessel
If Valve want to do this, I think the best way might be to have separate UI elements for environment variables and misc launch options, so you could do:
And then Steam could wrap all the container invocations - not just the actual game, but also the setup commands - in an inline shell script that exports the given environment variables, while only applying the launch options to the game itself.
In the latest beta version of SteamLinuxRuntime_soldier, you can try this out by running Steam with PRESSURE_VESSEL_RELAUNCH_CONTAINER=1 in the environment. It will make container startup slower, but it will mean that "adverb" commands in the launch options, including environment variables, get taken into account. Please comment to report how well it works for you.
For this feature, you want VERSIONS.txt to say SteamLinuxRuntime v0.20201124.0-11-g197f448 or higher.
Depending how well it works in terms of performance and functionality, we might make this mandatory in a later version, or keep it opt-in, or drop it entirely. It might even become enabled by default with an opt-out, but probably not for very long, because if it's good enough to be on by default, making it mandatory would let us delete quite a lot of relatively complex code.
PRESSURE_VESSEL_RELAUNCH_CONTAINER=1 seems to work as expected.
I didn't notice any significant launch slowdown, but I'm testing this with a powerful desktop CPU and Steam installed in an NVMe SSD. So I imagine that a laptop with an HDD should be a different story.
My usual test potato is a 9-year-old Lenovo T520 rescued from the "old laptops to be recycled" stack at the office, with a magnetic HDD (although admittedly a reasonably good 7200rpm model), which I had previously assumed was a worst-case-scenario for performance. On that machine, after dropping caches, total container setup takes around 30 seconds, of which the relaunch from this change costs 4 seconds; with a warm cache (probably more realistic), it's 14 seconds and this change costs us 2 seconds.
Unfortunately, @rbernonreports that a particular machine takes nearly 1 minute to set up the container (on SSD!). I'm not sure yet why that machine is so much slower than my test potato.