- Aug 19, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 18, 2020
-
-
Simon McVittie authored
-wrap eventually replaces itself with bubblewrap. If the bubblewrap process is killed, we want the adverb command to be terminated, passing the termination signal on to its own child process. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us have the following logic when sharing a container between multiple commands using -launcher and -launch: * For setup commands, don't wrap the launched command in the adverb. If the setup command starts background processes, they'll continue to run. This matches how installscript commands have historically worked for Windows (and Wine/Proton) games in Steam: the setup command is launched with system(), and can leak background processes like wineserver. * For the main game, wait for all processes to exit, by wrapping the launched command in the adverb, with --subreaper only. This matches how native Linux games, and the main command of Windows/Wine/Proton games, have historically worked in Steam. * When all processes belonging to the main game have exited, the -launcher can exit, at which point the subreaper that wraps it can clean up any background processes from the setup commands. --terminate-idle-timeout can be used to wait a few seconds before sending SIGTERM, if desired. Because the adverb now blocks SIGCHLD, we need to unblock it before running the child process; otherwise the child process will inherit the blocked signal, breaking things like g_spawn_async(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 11, 2020
-
-
Simon McVittie authored
If we want to be able to use --filesystem=/tmp, then we can't set up the X11 socket until after we're finished with that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 31, 2020
-
-
Simon McVittie authored
This is like `flatpak run --filesystem`, but for now much, much simpler; callers are responsible for not giving us paths that will be a problem. However, it's enough to bind-mount subdirectories of /tmp, which is what we need if we want to use them as IPC rendezvous points. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 29, 2020
-
-
Simon McVittie authored
pv_avoid_gvfs() can print GLib debug messages, which would corrupt a structured stdout. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the wrapped command prints structured data to stdout, we don't want to corrupt its output stream. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As noted in Flatpak and in GNOME/glib!490, there is a bug in GLib < 2.60 where g_spawn_* can sometimes deadlock while closing fds in a multi-threaded application. Work around this by making the affected fds close-on-execute ourselves, much like Flatpak does. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will make it easier to debug things going wrong in the adverb, by inheriting --verbose or PRESSURE_VESSEL_VERBOSE from the wrapper. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 21, 2020
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
pressure-vessel-with-lock has been renamed to pressure-vessel-adverb because now it has more capabilities than just taking a lock. This change should help the environments that are not able to normally run `bwrap`, like if we are in a Docker container or in a Flatpak app. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 02, 2020
-
-
Simon McVittie authored
This is necessary for Steam "compat tools" such as Proton. STEAM_COMPAT_DATA_PATH points to data associated with the current (compat tool, game) pair, for example the ${WINEPREFIX}. STEAM_COMPAT_TOOL_PATH doesn't exist yet, but I'm assuming that it will be set by some later version of the Steam client to point to Proton itself. STEAM_COMPAT_CLIENT_INSTALL_PATH points to the Steam installation. This is hopefully in the home directory, so hopefully we bind-mount it anyway; but if we don't, we should. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is desirable if we are running something other than the main game, for example steam-runtime-system-info or various preparatory steps involved in running Proton. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 17, 2020
-
-
Simon McVittie authored
I'd originally intended this to be done by a wrapper script, but in fact it's just as straightforward to do it here, which has the advantage that it keeps all the knowledge about the contents of the temporary runtimes directory in one place. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is primarily useful for testing and development: it lets us generate the temporary sysroot and inspect its contents, even if we are in a container (such as Docker or Flatpak) that does not give us the necessary privileges to run bubblewrap and create a new user namespace. In particular, this will make it more straightforward for us to check some of our assumptions when running on a non-Debian-derived host system. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is good for two reasons. In a Flatpak runtime, we will not be able to do tricks with arbitrary bind-mounts; if we want the host library stack, we will have to rewrite the mutable copy of the runtime to replace container libraries with symlinks into /run/host. Also, when not in a Flatpak runtime, having a mutable copy of the immutable runtime gives developers a chance to edit the runtime to inject workarounds or things they're testing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 12, 2020
-
-
Simon McVittie authored
This is one of the slower parts of the whole process, and not all games (or automated tests) even need it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 21, 2020
-
-
Simon McVittie authored
We already (optionally) use --unshare-pid since commit feb948ed. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 08, 2020
-
-
Simon McVittie authored
This improves isolation between the host system and the game, and can be used in conjunction with bwrap's init/reaper process to make game termination fully reliable (unlike subreapers, killing the init process automatically kills the entire pid namespace). One major down-side of doing this is that if the game uses process-ID-oriented APIs, for example older versions of <https://github.com/FeralInteractive/gamemode >, then they will not work, because the process ID inside the container is not the same as the process ID outside the container. Unfortunately, Steam's own tracking of the processes that belong to a game is one of the process-ID-oriented APIs that this harms, so this branch does not unshare the pid namespace by default, only when requested. We can use this to test whether it can be done without breaking Steam; We will probably need to cope with separate pid namespaces if we create new containers from inside a Flatpak environment. Also add an option to unload the gameoverlayrenderer.so module, which is not acceptable for production use, but at least works around this well enough to unblock further testing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 04, 2020
-
-
Simon McVittie authored
In practice we always want the host graphics stack, but maybe this will be useful when debugging. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There's very little refactoring so far: bind_runtime() is still basically monolithic, and takes individual bits of PvRuntime's state rather than a PvRuntime object. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
wrap.c is getting rather large, so the idea is that this will encapsulate everything related to swapping in a different /usr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 26, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
libdrm reads /usr/share/libdrm/amdgpu.ids to find information about AMD GPUs. So if we are using libdrm.so.2 from the host we also mount its libdrm folder. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 17, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In the case where we bind-mounted the entire root filesystem, since commit 77f3e3d7 we mounted it over the top of API filesystems like /dev, /proc, /sys. This results in /dev being mounted with the nodev option, which breaks a lot of normal functionality like /dev/null. Some games can work despite this, but only badly (Floating Point launches with indirect or software rendering and a horrible framerate), and the xterm activated by PRESSURE_VESSEL_SHELL=instead fails to launch because it can't create a pseudo-terminal. Adjust the order to get this right. Fixes: 77f3e3d7 "wrap: Make sure the intermediate bwrap object can be used as a base" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 10, 2020
-
-
Simon McVittie authored
It's a little confusing if we run p-v-wrap --test --verbose, which logs: pressure-vessel-wrap: Original argv: ... pressure-vessel-wrap: Checking for bwrap... and then exits. If we add one last line pressure-vessel-wrap: OK (/usr/bin/bwrap) then the result is clearer. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In some places we said exit status, but meant wait status (the status from waitpid() or similar, which encodes whether the process exited normally, the exit status if yes, the fatal signal if any, and whether a core was dumped). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 03, 2020
-
-
Jeremy Whiting authored
When --test is used check for bubble wrap executable and return 0 if found, 1 otherwise.
-
- Jan 23, 2020
-
-
Simon McVittie authored
This makes us match how Flatpak includes it, which makes our versions of Flatpak files more similar. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps us more in sync with the equivalent code in Flatpak, helping us to merge fixes from there. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 06, 2020
-
-
Simon McVittie authored
Non-OFD locks don't propagate across fork(), and bwrap needs to clone() itself (which behaves like fork() in this respect) to separate itself into a parent outside the container and a child inside the container. This change adds a weak dependency on Linux 3.15. If we run on an older version, everything should still *work*, but there will be a short period of time during which we have already decided to use the runtime, but it is not locked (and in particular not protected from deletion). Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is redundant with us passing the fd to be held by pressure-vessel-with-lock, and it causes bwrap to produce the wrong exit status (see https://github.com/containers/bubblewrap/issues/336 and https://github.com/containers/bubblewrap/pull/325 ). It should have been removed when the "pass the lock fd" code path was added. Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 13, 2019
-
-
Simon McVittie authored
When we're using a non-trivial runtime, we need to make pressure-vessel-with-lock available to the container. Previously, if your pressure-vessel installation was visible via your home directory (if shared), via $(realpath ~/.steam/steam), or via the current working directory at the time of running pressure-vessel-wrap, then it would exist in the container at the same path as outside the container, so this would work. However, if you have installed it in an alternative Steam library such as /media/big/library, none of these mount points would make it visible and bwrap would fail to run it. Circumvent this by mounting the relocatable pressure-vessel prefix on /run/pressure-vessel, which lets us run it via that path. Bug: https://github.com/ValveSoftware/steam-runtime/issues/204 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-