- Jan 05, 2021
-
-
Simon McVittie authored
We previously parsed this to decide whether we could use --unshare-uts, but we stopped doing that more than a year ago, in commit 210fbd8c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 17, 2020
-
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 10, 2020
-
-
Simon McVittie authored
We are not going to be able to do this from within Flatpak, and it is unsuitable for running runtimes other than Steam Runtime 1 'scout', for which the LD_LIBRARY_PATH runtime mostly already works. If we need an automatic fallback to running on the host for scout games, we can do that better by running `pressure-vessel-wrap --test`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, pid-based IPC between the Steam client and the game will fail. This is not expected to work if bwrap on the host is setuid, so it will not work for users of Debian, Arch linux-hardened, etc., but it's better than nothing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of asking flatpak-spawn to use Flatpak's D-Bus API, we can use pv-launch to talk to the same D-Bus API, which gives us one fewer component to align to get a working prototype. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 09, 2020
-
-
Simon McVittie authored
Since !173, we have been able to create symbolic links to graphics drivers anywhere on the filesystem, but that didn't mean the graphics driver would necessarily be usable, because the directory containing it would not necessarily be visible in the container. Add these directories to the list of directories to be "exported". Manual test (Debian on on Intel hardware, adjust as required for others): * Modify /usr/share/vulkan/icd.d/intel_icd.i686.json to use /opt/moved-from-usr/lib/i386-linux-gnu/libvulkan_intel.so * Move the real i386 libvulkan_intel.so to that location * ./run --verbose -- steam-runtime-system-info 2>&1 | tee container.log Resolves: #29 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/313 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 08, 2020
-
-
Simon McVittie authored
This module interposes in front of g_object_get(), and is known to cause crashes, even in programs that use GObject but not GTK, such as either pressure-vessel-launch or pressure-vessel-launcher (it's unclear which). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/286 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 30, 2020
-
-
Ludovico de Nittis authored
In case a user is experiencing some problems he might try to disable the import of Vulkan layers to better isolate the issue he is facing. Fixes: #37 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 24, 2020
-
-
Simon McVittie authored
As requested and later documented in <https://github.com/ValveSoftware/steam-for-linux/issues/6310>, Steam looks for compatibility tools in locations determined by this environment variable. Make them available in the container. When running in Flatpak, this will have no effect for compat tools in /app, but we should eventually get the Flatpak app's /app by a different route. Partial fix for https://github.com/ValveSoftware/steam-runtime/issues/302 (we also need to deal with compat tools in /usr/local/share and /usr/share, but that can't easily be done here, and is better addressed when we build the runtimes). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This provides a generic way to get OS-specific library directories, Vulkan layers' configuration, etc. into the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, we made ~/.steam available in the container as part of $HOME, but if it was a symlink outside $HOME or contained symlinks outside $HOME, their targets were not made available in the container. When using the experimental feature of a per-game home directory, we correctly made the targets of symlinks inside ~/.steam available, but not the target of ~/.steam itself (if it was a symlink). Fixes: https://github.com/ValveSoftware/steam-runtime/issues/291 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We might use this later to provide a read-only mount for files from the host OS that shouldn't ever be modified in the container, although we don't yet. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
On NixOS, all hard-coded paths in libraries point into /nix, so mounting it is going to be necessary (although not sufficient) to get pressure-vessel working on NixOS. Manual test, in an updated SteamLinuxRuntime or SteamLinuxRuntime_soldier depot: ./run -- xterm sudo mkdir /nix sudo touch /nix/not-really ./run -- xterm and in the xterm: ls -al /nix Expected result: /nix exists in the container if and only if it exists outside the container. Partially addresses https://github.com/NixOS/nixpkgs/issues/100655 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
Ludovico de Nittis authored
Soldier and Scout include a limited set of fonts that doesn't cover all use cases. For example it is missing the necessary glyphs for Asian languages. For this reason, instead of just using these fonts, we bind the host's ones. This requires an additional configuration file that tells to fontconfig the location of these fonts. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@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>
-