- Nov 24, 2020
-
-
Simon McVittie authored
This function won't work in Flatpak, so we make sure that we only call it when we are *not* in Flatpak. The assertion should match that. This fixes the ability to run: ./pressure-vessel/bin/pressure-vessel-wrap -- xterm when not in a Flatpak environment, which in principle is meant to work (at least on reasonably normal FHS operating systems), although it isn't regularly tested. Thanks to NixOS contributor moben on Github, who spotted this while debugging. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 17, 2020
-
-
Simon McVittie authored
If we want to deal with strange operating systems that use a non-standard filename for ld.so.cache, we'll have to special-case it. There's little extra cost to doing this because we already need to understand how ld.so.cache works, to be able to generate our own with different search paths. In situations where we just want a quick container to be able to inspect the runtime, we can deal with this by mounting all of /etc read-only. For the final container, we already iterate over all the files in the runtime's /etc, which will "naturally" include ld.so.cache and alternatives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 26, 2020
-
-
Ludovico de Nittis authored
If necessary, in runtime.c we should access the original environment instead of the global one, because it might have been edited. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 22, 2020
-
-
Simon McVittie authored
Now that GIO_MODULE_DIR has been backported into scout's GLib, we can disable GIO modules completely, instead of loading them but then not using them. This avoids some misleading warnings (#32). This will not be completely effective on non-Debian systems until we also patch scout's GLib to make GIO_MODULE_DIR take precedence over the hard-coded legacy search path /usr/lib/gio/modules. The unit test for this is still in tests/pressure-vessel/utils.c for now. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 19, 2020
-
-
Ludovico de Nittis authored
The list of locked environment variables should include all the vars that we decided to want, or avoid. Also use `extra_locked_vars_to_unset` everywhere instead of directly unsetting a variable. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 06, 2020
-
-
Ludovico de Nittis authored
For LD_PRELOAD we want to use the value `-launcher` might be receiving from `-launch`, so we don't want to lock it's value in `wrap`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 01, 2020
-
-
Ludovico de Nittis authored
If we want to pass all the possible variables that a user might have set in its environment, we need a mechanism to lock the variables that pressure-vessel is editing (e.g. LIBGL_DRIVERS_PATH), variables that we want to keep unset because will be wrong in the new container (e.g. FLATPAK_ID) and variables that should inherit their value from the host system (e.g. DISPLAY). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 30, 2020
-
-
Ludovico de Nittis authored
If we use the `original_environ` for all the long-running childs, they'll not be affected even if later on we edit the environ with `g_setenv()`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
In the future this option might be used to leverage some of the 'pressure-vessel-launcher' features, like locking specific environment variables. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 28, 2020
-
-
Simon McVittie authored
This avoids duplicating it in the command-line tools. The test is still in tests/pressure-vessel/ for now, because it needs testutils.py, which uses its own location to find G_TEST_SRCDIR. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 25, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
This is preparation for combining pressure-vessel with steam-runtime-tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
This lets regression tests inspect them. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Part of pressure-vessel#6. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This takes over responsibility from the shell scripts that currently wrap this executable. When combined with a Steam update, this should resolve a lot of issues involving paths outside the current working directory. Resolves: pressure-vessel#4 Resolves: pressure-vessel#11 Resolves: pressure-vessel#12 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/217 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/236 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/257 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 07, 2020
-
-
Simon McVittie authored
Recent versions of Steam set this when running setup commands in the context of a particular app, so that the setup commands can find their home directory if unsharing $HOME. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
SteamHTMLSurface and SteamVR use this as a rendezvous directory for IPC. A future version of pressure-vessel should have a more strict mode that shares less with the host. Resolves: pressure-vessel#10 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Looking at environment variables is still part of pv-wrap, but the command-line part now happens in pv-adverb. This means the launching scripts for the "session" mode, which use pv-launch to run the main game command in a previously-set-up pv-launcher environment, can direct pv-adverb to run an interactive shell instead of or in addition to the actual game. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This gives us access to the same tricks that Flatpak uses to get host paths into the container in a more robust way: in particular, it sorts paths to put parent before child, and exports symbolic links as symbolic links plus a separate mount point for the target (which we previously did for the subdirectories of ~/.steam, but nowhere else). Resolves: pressure-vessel#2 Resolves: pressure-vessel#18 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 04, 2020
-
-
Simon McVittie authored
This lets us create /run/host and /run/pressure-vessel unconditionally, even if we're mostly using the host filesystem rather than a runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that we export each subdirectory of the root separately, there's nothing to stop us from using the same function in the runtime and no-runtime cases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us separate them between those that will be processed as if via Flatpak --filesystem=host, and those that are dealt with individually. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We want these to come after every other bind-mount. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we're given a relative path, make it absolute before transforming it for the host. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
A reasonably common case is that the value on the host and in the container will be the same. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When we have more than one layer of adverbs, this provides a way to tell which one we are. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 02, 2020
-
-
Ludovico de Nittis authored
When pressure-vessel is launched from inside a Flatpak container we are not allowed to create a parallel bwrap container. Using flatpak-spawn --host we can workaround this limitation. Please note that the permission to talk to "org.freedesktop.Flatpak" is required for this to work. For example you can use: `flatpak run --talk-name=org.freedesktop.Flatpak com.valvesoftware.Steam` Hopefully in the future we will be able to avoid the permission requirement of "org.freedesktop.Flatpak". Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
We keep a list of known environments that we might need inside the final bwrap container that will be launched by the host system. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
pressure-vessel had a few hard coded assumptions about the host system and where to look at for the graphics provider. For example it was assumed that the root was the same host system used by both pressure-vessel current environment (where pressure-vessel-wrap runs) and also later on by `bwrap`. But when we run pressure-vessel in a Flatpak container, the final `bwrap` command is expected to be executed against the real host system (mounted in `/run/host`, in Flatpak). Also when we are in a Flatpak container we might want to pick the graphics stack from the host system (`/run/host`), from the Flatpak container itself or it could even be a completely separate one. (T22373, T22371) Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 01, 2020
-
-
Simon McVittie authored
The default for a FlatpakBwrap object is to copy the calling environment as a base for the environment that it will build up. However, that's wrong if we are going to merge more than one FlatpakBwrap together: the merged FlatpakBwrap's argv will be appended to the destination FlatpakBwrap, but the merged envp will overwrite the corresponding variables in the destination. Avoid this by making sure that every time we merge two FlatpakBwrap objects, one of them has an empty environment. Resolves: T23422 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 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>
-