Document how Proton can escape from the container
Separately, a way to un-runtime (and un-container?) might be interesting. We very occasionally have a reason to run a binary from the host system (ping and xdg-open). We currently record the original LD_LIBRARY_PATH value and restore it, but I guess that's going to be broken in the new runtime container.
Running binaries from the host system, in the container, is not possible. (That's part of the point of being in a container.)
ping
You can't run ping in the container because it relies on being setuid root, and processes in the container are forbidden from becoming privileged. @aeikum, how badly does Wine need this?
In a Flatpak environment, programs wouldn't usually be allowed to escape from the container because it's a security boundary, but programs with arbitrary code execution privileges from --talk-name=org.freedesktop.Flatpak
(which means the container isn't a security boundary any more) can use flatpak-spawn --host -- ping ...
.
If Wine badly needs the ability to run ping
on the host, because pressure-vessel doesn't currently make any attempt to be a security boundary, we could run an instance of pressure-vessel-launcher
on the host system, and drop in a ping
shell script that looks something like this:
#!/bin/sh
set -eu
exec /run/pressure-vessel/pv-from-host/bin/pressure-vessel-launch --socket=/run/pressure-vessel/launcher-on-host.sock ping "$@"
But that won't work for a Steam client that runs as a Flatpak app, and neither would the scout versions of Proton (5.0 or older), in the LD_LIBRARY_PATH
Steam Runtime, running ping
right now.
steam
Ability to run things like steam steam://install/440
is tracked as a separate issue: pressure-vessel#7.
xdg-open
For xdg-open, the scout and soldier runtimes contain Flatpak's reimplementation of xdg-open
, which uses IPC to https://github.com/flatpak/xdg-desktop-portal to throw the URL outside the container for handling - so if the user has xdg-desktop-portal
and at least one suitable backend installed, you can xdg-open https://example.com/
and it will work. If the user does not have xdg-desktop-portal
, then no.
xdg-desktop-portal
and its -gtk
backend are available since Debian 8 (where I maintain them for Flatpak's benefit) and Ubuntu 16.04 (where they were added in 2019 for Snap's benefit). They are not officially present in SteamOS 2, but xdg-open isn't going to work very well in the SteamOS Big Picture compositor anyway.
Or we could potentially use the same trick as for ping
, although in general that won't work for file:///
URIs, because the container's view of the filesystem is not the same as the host's (I think xdg-open has a special case for those, and if it doesn't, it should).
Other executables
Does Proton/Wine escape from the container to do anything else?