Cannot access filesystem outside container on Sniper runtime

[stormytuna]

Your system information

• Steam Runtime Version: Steam Runtime 3 'sniper'
• Distribution (e.g. Ubuntu 18.04): NixOS Unstable
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: https://gist.github.com/stormytuna/4a03ef04cc973ccdc00eef4ef20473cb
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: None
• Listed versions: https://gist.github.com/stormytuna/8e515118b8d9ff2c19700112640693b4

Please describe your issue in as much detail as possible:

Some Steam games (in this case tModLoader) have development tools that rely on the user installing sdks or other software on their system (in this case dotnet). Previously we could locate these tools by running the which command. Is there a way for our game to enable read access to [portions of] the host filesystem, or a way to execute processes outside the sandbox?

[smcv]

I'm writing this with an audience of app/game maintainers in mind more than end users, so if you're a gamer but not an app/game/mod developer, it might not be 100% relevant to you - it might be more relevant to @Chicken-Bones and other tModLoader contributors.

a way to execute processes outside [the Steam Linux Runtime]

This is technically already possible, but the way it works bypasses all of the things that Steam does to try to help to make your app/game portable between different distributions - so it will be up to your app/game to deal with all the various possible error conditions (not just the obvious "there is no foobar in the PATH", but also "there is a foobar but it doesn't work", "there is a foobar but its directory layout is totally different", "there is a foobar but it's 10 years old", and 10 years from now, "there is a foobar but it's 10 years newer than my codebase expected").

I'm going to look at improving the documentation around this, so that we can point developers and mod authors towards it, while making sure that the risks and limitations are documented in the same place as how to achieve it. Right now I'm intentionally being non-specific, until we have the improved documentation in place; but I wanted to respond here first and say that a plan does exist.

Wherever possible I'd recommend treating this facility as something that is available for debugging and development, but is not critical-path for the basic end-user-facing functionality of whatever app/game is in use. If I'm reading correctly, tModLoader wants .Net for mod developers (perhaps to run a C# compiler or similar?), but users who just want to run a modded game don't need it? That's probably a reasonable way to use this - mod developers presumably have lower expectations about perfect compatibility with arbitrary distros several years into the past or future.

For the core functionality of the app/game itself, the design is a lot like Flatpak: the only things you can count on are whatever is provided as part of the runtime (which notably doesn't include .Net or other "big" language frameworks like Java), and whatever is bundled in the app/game.

If the use-case for this is something non-interactive like a compiler, providing it as a Docker/Podman/Toolbx container image outside the scope of Steam or SLR might be an alternative to integrating it into a Steam app/game? The official SDK for building apps/games that run under SLR is not provided via Steam either, because Steam isn't really designed for that: we provide a Docker/Podman/Toolbx image because that's often a better fit for that sort of developer-facing use-case.

the sandbox

The Steam Linux Runtime is a container, but not a sandbox: there is no meaningful security boundary (the most it does is to protect against accidents). For issues like this one, that's a good thing - it means we can provide the mechanism you're asking for, without having to say "no, because that would be a security vulnerability".

to enable read access to [portions of] the host filesystem

You actually already have read access to most of the host filesystem, but you can't simply run arbitrary commands from it, because the container's library stack is set up to be compatible with SLR 3.0, rather than being compatible with whatever host system the user might be using (and sometimes those can be mutually exclusive, because Linux distributions aren't fully compatible with each other).

[Chicken-Bones]

You have understood our requirements perfectly. Ideally the game itself would continue to run in the compatibility environment even for modders, and only external tooling which we do not ship (primarily the dotnet sdk for building C#) would be executed in the host system.

Even though it would be possible to ship a dotnet sdk as an optional component, we would rather reference the one on the user's system, providing them more control over their toolchain and keeping it in line with other development software they may have such as IDEs.

[smcv]

Ideally the game itself would continue to run in the compatibility environment even for modders, and only external tooling which we do not ship (primarily the dotnet sdk for building C#) would be executed in the host system.

That is certainly something that you could do. The way you can do this, which I alluded to above, is now documented:

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#running-commands-outside-the-container

If you're familiar with Flatpak, the way this works is very similar to flatpak-spawn --host (which is not allowed for most Flatpak apps because it would be a sandbox escape, but our use-case in SLR is not intended to be a security boundary, therefore we allow it).

Or, if you're not familiar with Flatpak, you can think of it as being a bit like running a sshd on the host system, and using a ssh client inside the SLR container to connect to it. (It doesn't use the ssh protocol, but the idea is vaguely similar.)

As with ssh and flatpak-spawn, if you make use of this mechanism, you'll have to coordinate between two different "worlds", with different views of the filesystem: the one inside the container, and the one on the outside where you run dotnet.

If the use-case for this is something non-interactive like a compiler, providing it as a Docker/Podman/Toolbx container image outside the scope of Steam or SLR might be an alternative to integrating it into a Steam app/game?

This continues to be something you could consider as an alternative way to support mod developers.