- Nov 28, 2024
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 21, 2024
-
-
Simon McVittie authored
Compatibility tool 1070560 used to be named `Steam Linux Runtime`, but is now `Steam Linux Runtime 1.0 (scout)`. With the current naming, we should only say `Steam Linux Runtime` if we are talking generically about the whole family of container-based runtimes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These don't actually affect the behaviour of pv-wrap, but they're sufficiently closely-related that it makes sense to document them here. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Followup from steamrt/tasks#404 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Followup from steamrt/tasks#578 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 18, 2024
-
-
Simon McVittie authored
Sometimes our current uid will not be present in /etc/passwd. For example, when using systemd-homed the equivalent of a passwd(5) record is synthesized by libnss_systemd. A similar thing could happen when using a remote user directory like LDAP, or for the group database. Inside the container, we have the basic nsswitch plugins from glibc (notably libnss_files, which reads /etc/passwd and /etc/group), but we do not have access to non-standard nsswitch plugins like libnss_systemd or LDAP. This can cause crashes or bugs in games that assume that `getpwuid(getuid())` will always succeed (like Factorio), especially if they do not respect `$HOME` (like Factorio). Instead of bind-mounting the host system's /etc/passwd and /etc/group as-is, we can synthesize a /etc/passwd and /etc/group that are guaranteed to contain at least our uid and primary gid, matching what Flatpak does. Flatpak generates very minimal files that list our uid and gid, plus the default overflow uid and gid 65534 (labelled as `nfsnobody` for historical reasons). However, pressure-vessel has historically provided more complete files, so it's conceivable that a game might be relying on being able to resolve (for example) root as uid 0; so we copy everything from the host /etc/passwd and /etc/group, excluding only the line(s) that would duplicate the one we synthesize. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/705 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 05, 2024
-
-
Simon McVittie authored
It's difficult for users of non-Debian-derived distros to select the runtime's SDL, especially if they don't know whether the game is 32- or 64-bit, because the expansion of `$LIB` and `$PLATFORM` varies between distro glibc builds. However, we can normally predict `$LIB` and `$PLATFORM` well enough to do the right thing programmatically. For example, if `$PLATFORM` expands to `i686` in 32-bit processes and `xeon-phi` in 64-bit, then we can create symlinks at `/tmp/XX/i686/libSDL2-2.0.so.0` and `/tmp/XX/xeon-phi/libSDL2-2.0.so.0`, and then set `SDL_DYNAMIC_API='/tmp/XX/${PLATFORM}/libSDL2-2.0.so.0'` to have the runtime linker dynamically select the correct word size. While I'm here, we might as well provide the same setup for SDL3. steamrt/tasks#578 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 30, 2024
-
-
Simon McVittie authored
This will let us highlight warnings and fatal errors from bwrap as such. In particular, if bwrap fails with a fatal error, putting the <3> prefix on it will ensure that it's highlighted as an error. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can only add one directory to the search path for VDPAU drivers, so to support both 32- and 64-bit, we have to multiplex via ld.so dynamic string tokens like `${PLATFORM}`. Unfortunately, we were creating symbolic links pointing to paths like /overrides/x86_64-linux-gnu/vdpau (no "lib" infix) rather than the correct /overrides/lib/x86_64-linux-gnu/vdpau, so the VDPAU driver would not actually have been found. Fixes: 4f3d2d4b "pv-runtime: Delegate setup of VDPAU to pv-adverb" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 15, 2024
-
-
Simon McVittie authored
In current Mesa versions, typically these are pulled in via explicit linking that generates a `DT_NEEDED` ELF header, either in individual DRI drivers in very old Mesa, in the Gallium "megadriver" in intermediate Mesa versions like the one in Debian 12, or in `libgallium-${VERSION}.so` in newer Mesa. However, Mesa merge request https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 suggests demoting the dependency on `libdrm_amdgpu.so.1` from `DT_NEEDED` to `dlopen()`. Changing that dependency from declarative to imperative breaks our ability to follow it, resulting in the container's older `libdrm_amdgpu.so.1` being used. In principle there's nothing to stop the same thing from happening for any of the libraries in the libdrm family, so look for all of them. For future-proofing, I've included all available drivers even if they are not available on x86 (but excluding exynos and omap, which seem to be only for 32-bit ARM hardware, which is probably no longer interesting). Tested-by: Dmitry Osipenko Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 20, 2024
-
-
Simon McVittie authored
steamrt/tasks#520 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Steam Linux Runtime 1.0 (scout) wants access to this. steamrt/tasks#520 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 12, 2024
-
-
Simon McVittie authored
libxkbcommon is not really a graphics driver dependency as such, but it can end up being pulled in by graphics stack components, for example MangoHUD 0.7.2. libxkbcommon-x11 looks into private data structures from libxkbcommon, which is a reasonable thing to do since they come from the same source code and are upgraded at the same time, but can cause crashes if we pick up one but not the other from the graphics stack provider; so if we pick up libxkbcommon as a dependency of MangoHUD, we also need to take the matching libxkbcommon-x11 if it exists. If the graphics stack provider has libxkbcommon but not libxkbcommon-x11, there's really nothing we can do about that, so we will have to combine this change with trying harder to get Steam client packaging to pull in libxkb-common-x11.so.0. steamrt/tasks#530 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously this was part of pv_runtime_collect_libc_family(), but in fact it's equally applicable for other libraries. For example, if we are using the host's libxkbcommon.so.0, we'll also want the host's libxkbcommon-x11.so.0 if at all possible, because libxkbcommon-x11 uses private data structures from libxkbcommon and will crash if they are not sufficiently similar. steamrt/tasks#530 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 22, 2024
-
-
Simon McVittie authored
The warnings were fixed in recent flatpak versions, so we no longer need this delta. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional changes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 13, 2024
-
-
Simon McVittie authored
For historical reasons g_qsort_with_data() "only" works with up to 2**31 items, so it won't necessarily work for pathologically large arrays and therefore is deprecated. The advantage of g_qsort_with_data() and its replacement g_sort_array() is that GLib guarantees that they are a stable sort (will not permute items that already compare equal), which is not a guarantee for glibc's qsort() and qsort_r(). However, in each of these places we are sorting the keys from a hash table, which are unique anyway, so there is no advantage to a stable sort. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 07, 2024
-
-
Simon McVittie authored
Unlike XDG_CONFIG_HOME and XDG_DATA_HOME, these search paths are expected to be read-only, making it much less likely that a game or app component will misbehave if they contain a dangling symlink. Also unlike XDG_CONFIG_HOME and XDG_DATA_HOME, these paths are much more likely to contain OS-related path elements that can cause container runtime regressions, such as /var/cache (steamrt/tasks#434) and /var/lib (steamrt/tasks#493). A regression risk with this change is that if a user has set for example `XDG_DATA_DIRS=/offload/data:/usr/local/share:/usr/share`, since 0.20240301.0 the result has been that /offload/data has been shared with the container, which means apps and games in a SLR container will load icons, .desktop files, etc. from that location. No longer doing this is both good and bad. It's good because it makes the container more self-contained again, but it's bad because users might have come to rely on `/offload/data` being available, which would no longer be the case after this change. steamrt/tasks#493 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the user has /var/run as a directory (not a symlink), and if they (unwisely) run with --filesystem=/var/run, then that would prevent us from creating the symlink `/var/run -> ../run`. steamrt/tasks#493 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need to prevent /var/lib/dbus (and parent directories like /var/lib) from being shared with the container. Otherwise, a /var/lib/dbus/machine-id that is a regular file on the host can prevent us from creating it as a symlink (to /etc/machine-id) in the container. steamrt/tasks#493, steam-runtime#688 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 06, 2024
-
-
Simon McVittie authored
My understanding is that these libraries are dlopen'd by other parts of the Nvidia driver for confidential-computing GPGPU use-cases, and unlikely to be critical for gaming. There are currently two implementations, one that depends on OpenSSL 1.1 and one that depends on OpenSSL 3.0. The way they are packaged in Ubuntu means that in 24.04, the one for OpenSSL 1.1 is present but does not have its dependencies satisfied, leading to confusing warning messages from capsule-capture-libs that could confuse our users. Silence those messages by using the new "quiet:" pattern prefix. (The message is actually reduced to LOG_DEBUG level rather than being silenced, so CAPSULE_DEBUG=tool will reinstate it if someone needs to look at capsule-capture-libs behaviour in fine detail.) steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us highlight warnings and fatal errors from capsule-capture-libs as such. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 02, 2024
-
-
Simon McVittie authored
steamrt/tasks#416 Mitigates: https://github.com/canonical/steam-snap/issues/397 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 31, 2024
-
-
Simon McVittie authored
This is a redo of commit d6a519f5 "pv-runtime: Add a mechanism to take custom CA certificates from the host" which aims to be more robust against host operating systems that might not have the Debian-compatible layout that we expect. This reverts commit 9e3d9c85. steamrt/tasks#416 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 26, 2024
-
-
Simon McVittie authored
This removes most of the `#if 0` from `flatpak-utils.c`: everything with non-trivial dependencies was moved to other translation units upstream. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 19, 2024
-
-
Simon McVittie authored
Previously we assumed that the hard-coded directory used to dlopen gconv modules matched the realpath() of the directory containing libc.so.6, disregarding any compatibility symlinks: for example, on Red Hat, 64-bit gconv modules are in /usr/lib64/gconv, and on Debian they're in /usr/lib/x86_64-linux-gnu/gconv. However, this turns out not to be true on Void Linux, where /usr/lib64 -> lib is a non-canonical path, but the hard-coded path that will be used to load iconv modules is /usr/lib64/gconv anyway. We cannot simply set GCONV_PATH, because apparently setting `GCONV_PATH=/usr/lib/gconv:/usr/lib32/gconv` will break 32-bit applications: unlike the equivalent with LD_LIBRARY_PATH, a 32-bit application would try and fail to load the 64-bit module from /usr/lib/gconv (it will fail to load because its word size does not match the word size of the process), and then will not fall back to /usr/lib32/gconv as one might expect. Luckily, on Void Linux, the libdl dynamic string token ${LIB} has been chosen such that the correct path for each architecture's gconv modules is /usr/${LIB}/gconv. We can use this as an additional guess at the necessary mount point for the gconv modules, mounting /usr/lib/gconv onto both /usr/lib/gconv and /usr/lib64/gconv - that way, it doesn't matter whether the path hard-coded in glibc matches our old heuristic or our new heuristic, because either one will work. steamrt/tasks#477, ValveSoftware/steam-runtime#680 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 18, 2024
-
-
Simon McVittie authored
Our older runtimes are symmetrical, so the vast majority of libraries (and in particular, the ones that need aliases for an alternate SONAME) are available for both x86_64 and i386. However, in some of our newer runtimes like medic, we've started dropping i386 libraries that don't strictly need to exist in order to save some space. This means we can't necessarily assume that libraries that need aliases will exist for every architecture, so we shouldn't emit warnings if they turn out not to exist. steamrt/tasks#367 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
On x86, the 0'th architecture is hard-coded to be x86_64. On other platforms, there is only one architecture, which is whatever we are compiling for. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 17, 2024
-
-
Simon McVittie authored
Since updating our Flatpak-derived code, every time we start a container we log messages like: N: Not replacing "/etc/vulkan/implicit_layer.d" with tmpfs: Path "/etc" is reserved by the container framework We only import selected directories from /etc into the container's /etc, and none of the directories below /etc/vulkan are among them, so there is actually no need to mask these directories. Silence the warning by not attempting to mask them. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This was implemented in a way that assumed it would only be enabled on specially-flagged developer systems, making it acceptable for the implementation to be non-robust and make assumptions about the host systems on which it would be enabled; but current Steam betas enable it for the steamwebhelper unconditionally, which would cause serious regressions on non-Debian-derived, non-Arch-derived host OSs. Revert the addition of this feature to avoid regressions. Before reinstating it, we will either need to arrange for Steam to enable it conditionally as previously planned, or make the implementation fail gracefully and harmlessly on non-Debian-compatible host systems. This reverts commit d6a519f5. steamrt/tasks#416 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 09, 2024
-
-
Simon McVittie authored
Now that steam-runtime-tools requires GLib 2.58, all backports older than that no longer conflict with s-r-t's backports (and they're skipped anyway as a result of the version checks). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is intended to be a developer-only feature, so it makes some assumptions about the host system: we assume that there is a Debian-compatible TLS certificate store (as seen on e.g. Debian and Arch) with a CAfile at /etc/ssl/certs/ca-certificates.crt and a CApath at /etc/ssl/certs. There is no attempt to make this as robust as we would usually want for an end-user-facing feature, and it will fail hard (exit with an error) rather than trying to continue in the face of adversity. steamrt/tasks#416 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 25, 2024
-
-
Simon McVittie authored
Many of the changes are `#if 0`. Main changes that have a practical effect on steam-runtime-tools: * Some former g_debug() has been promoted to g_info(). * The majority of flatpak-run.c is now `#if 0`. The parts we use have mostly moved to `flatpak-run-*.c`. * Backports from newer GLib are now in their own translation unit. Some of them are `#if 0` because they are redundant with a copy in <steam-runtime-tools/glib-backports-internal.h>. * Flatpak now supports using the Wayland security context extension to mark Wayland connections as belonging to a specific (app ID, instance ID) pair; but this is not relevant for pressure-vessel, so we don't enable or use this feature. * Flatpak now supports using $WAYLAND_SOCKET to create Wayland connections with the security context extension, or optionally allows apps to inherit it directly; but this is not useful for pressure-vessel because it only accepts a single client connection, whereas a Steam game might consist of multiple Wayland clients, so we don't enable or use this feature. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 14, 2024
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 13, 2024
-
-
Simon McVittie authored
flatpak_bwrap_steal_fds() is private in Flatpak 1.14.8, but we make it extern because another part of pressure-vessel needs it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional changes: all the changes are `#if 0` in pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
With older GLib, `libglnx.h` was enough to provide `g_fdwalk_set_cloexec()`, but with newer GLib, `glib-unix.h` is required. Origin: https://github.com/flatpak/flatpak/pull/5737 Fixes: 7fac9ccb "pv-wrap: Use g_fdwalk_set_cloexec() instead of flatpak_close_fds_workaround()" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 25, 2024
-
-
Simon McVittie authored
Since snapd 2.62, we do not need any special workarounds, and since https://github.com/canonical/steam-snap/pull/367 Canonical's Steam snap app has required snapd 2.62. This change is in the stable channel as of 2024-04-25, which means that the Steam snap app will refuse to install onto systems with an older snapd until the snapd has been upgraded. For now, disable the workarounds by default but keep them implemented. After we have a beta -> stable cycle without incident, we can delete their implementations. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Many of the changes are `#if 0`. Main changes that have a practical effect on steam-runtime-tools: * flatpak_exports_add_path_expose(), etc. return a GError, which we convert into a warning- or info-level message in the same way that flatpak_context_export() would. To facilitate this, add helper functions in pressure-vessel/exports.c. * flatpak-context.c is no longer included here, and all of the declarations in its header are now `#if 0`. The only parts that we use are the enums in the header, which are still present; the array `dont_mount_in_root`, which has been moved into wrap-setup.c; and the new `log_cannot_export_error` function, which has been moved into exports.c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-