Cannot access filesystem outside container on Sniper runtime #717
Comments
|
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.
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 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 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".
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). |
|
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 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. |
That is certainly something that you could do. The way you can do this, which I alluded to above, is now documented: If you're familiar with Flatpak, the way this works is very similar to Or, if you're not familiar with Flatpak, you can think of it as being a bit like running a As with
This continues to be something you could consider as an alternative way to support mod developers. |
|
Thankyou for the documentation. I was able to follow the instructions to execute commands on the host on a Linux machine, however I had trouble when running some tests under WSL2. When running: Running the following in a terminal on the host also shows the error |
|
Yes, this feature requires a working D-Bus session bus (and I'm sure there are other Steam features that do, too). If WSL2 doesn't normally provide one of them, it might help to run your debugging session as something like which will give you a session bus as long as that shell is running; and then run Steam from inside that environment. Steam-for-Linux is designed to run on an actual Linux desktop system; if it runs successfully on WSL2 as well then that's a bonus, but WSL2 has some limitations that mean not everything is going to work. |
If you are launching a sniper container directly, without using Steam, then You can provide a mockup of this service by running something like this, inside the same D-Bus session as all the commands that will try to talk to it: and waiting for it to start (it will show some information on standard output when it is ready for use). |
|
Thanks, I was able to upgrade my WSL2 testing environment with Our game currently uses |
|
If your engine/runtime library has an API to do what you want to do without launching a subprocess, I'd recommend trying that first. For example SDL has The next best thing is that you can/should keep using the Please try to avoid using |
|
Thankyou for your advice, it will be followed. I verified that |
Your system information
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 thewhichcommand. 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?The text was updated successfully, but these errors were encountered: