- Aug 07, 2024
-
-
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 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>
-
- 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>
-
- Apr 19, 2024
-
-
Simon McVittie authored
This avoids a failure mode seen on ClearLinux where including /var/cache in XDG_DATA_DIRS would prevent pressure-vessel startup. It also preemptively avoids the same situation potentially happening for /run/host, /run/parent and similar paths. steamrt/tasks#434 Resolves: https://github.com/ValveSoftware/steam-for-linux/issues/10789 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This matches the behaviour of FlatpakExports, except that instead of silently ignoring these paths like FlatpakExports would, we want to log a warning if necessary. steamrt/tasks#434 Helps: https://github.com/ValveSoftware/steam-for-linux/issues/10789 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 19, 2024
-
-
Simon McVittie authored
If bwrap is setuid root, we were previously pushing LD_LIBRARY_PATH into it via bwrap --setenv, but it turns out that doesn't actually work: the fact that bwrap is setuid means that the environment variable won't stick. The result is that pv-adverb doesn't have the host system's glibc in its library search path and can't start. We can avoid this problem by using ld.so(8) to invoke pv-adverb with a specified search path, and then telling pv-adverb to finish setting up the environment before it runs ldconfig(8) to regenerate the ld.so.cache. Instead of second-guessing which environment variables glibc is going to filter out in setuid executables, we just serialize all of them - with `--env-fd` there's no longer any real reason not to. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 13, 2024
-
-
Simon McVittie authored
This allows us to make /usr/share/libdrm a symlink to /snap/steam/171/graphics/usr/share/libdrm. If we don't do that, libdrm will not be able to load data files like /usr/share/libdrm/amdgpu.ids from it. Or, if Snap's libdrm has been configured or patched to read directly from /snap/steam/171/graphics/usr/share/libdrm, we want that to be possible too. Before this can be enabled by default, snapd's AppArmor profile needs to be fixed to allow it: https://github.com/canonical/steam-snap/issues/359 Helps: https://github.com/ValveSoftware/steam-runtime/issues/586 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will make it easier to verify whether a particular workaround is still needed, for example by setting a game's Steam launch options to: PRESSURE_VESSEL_WORKAROUNDS="-steam-snap#370" %command% Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 19, 2024
-
-
Simon McVittie authored
There's no reason why this particularly needs to be pressure-vessel-specific, and since commit 7627197e "steam-runtime-tools: Separate out modules not in the shared library" we can share code between pressure-vessel/ and bin/ without enlarging the shared library. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 02, 2023
-
-
Simon McVittie authored
This avoids gcc warnings by making use of the fact that gcc allows casts of any function pointer to/from a function with no result and no arguments, which both gcc and GLib use as a stand-in for a function with unspecified result and unspecified arguments. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 30, 2023
-
-
Simon McVittie authored
Unlike most POSIX functions, instead of returning -1 and setting errno on error, pthread_sigmask() returns a positive errno-like value on error. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 30, 2023
-
-
Simon McVittie authored
If we can't chmod the file, we should say what the current owner and permissions look like, to assist debugging. In particular, this is likely to happen on NTFS or when operating on a directory owned by a different user. For example, if the filesystem is owned by root (steam-runtime#544) we might say: Unable to change mode of ... from 0777 (owner: "root", group: "root", non-member) to 0644: ... or if the file is owned by the current user but the filesystem does not allow chmod anyway (steam-runtime#606) we might say: Unable to change mode of ... from 0755 (owner: current user, group: "users") to 0644: ... Helps: https://github.com/ValveSoftware/steam-runtime/issues/434 Helps: https://github.com/ValveSoftware/steam-runtime/issues/460 Helps: https://github.com/ValveSoftware/steam-runtime/issues/477 Helps: https://github.com/ValveSoftware/steam-runtime/issues/491 Helps: https://github.com/ValveSoftware/steam-runtime/issues/544 Helps: https://github.com/ValveSoftware/steam-runtime/issues/606 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 06, 2023
-
-
Ludovico de Nittis authored
When creating the JSON manifests, we were simply naming them sequentially, as an easy way to avoid conflicts. However, since Vulkan Loader 1.3.234, it is possible to select which driver to use by listing their names in the environment variable `VK_LOADER_DRIVERS_SELECT`. This functionality would not work in pressure-vessel, unless we keep the original JSON manifest name. With this commit now we always reuse the JSON manifest basename. In the rare events where this could cause a conflict, we create unique sub directories to avoid issues. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 28, 2022
-
-
Simon McVittie authored
If we don't have any better way to choose an implementation, using lexicographic order makes it a little easier to compare log files. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 21, 2022
-
-
Simon McVittie authored
Otherwise, we could end up loading drivers or layers in an unexpected order, with the layer numbered 10 loaded before the layer numbered 2. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 07, 2022
-
-
Simon McVittie authored
Recent Meson versions have warnings if you add the subprojects directory as an include path, because the way Meson wants to consume subprojects is by the subproject's build system producing a Meson dependency object that encapsulates its include directory. libglnx seems to be set up to have the libglnx directory be its include path instead: for example, ostree (by the author of libglnx) already uses "libglnx.h" or <libglnx.h> everywhere. Do the same here. Flatpak equivalent: https://github.com/flatpak/flatpak/pull/4842 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 31, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This requires switching it from flatpak_canonicalize_filename() to g_canonicalize_filename(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The names were confusingly similar, but _srt_util_set_up_logging() was actually orthogonal to pv_set_up_logging(): the former was about the disposition of the stdout and stderr fds, whereas the latter was about the GLib log handler. Rename it to make the difference clearer. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 27, 2022
-
-
Simon McVittie authored
We wrote this, so it's fine to relicense it more permissively, from LGPL to MIT. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 20, 2021
-
-
Simon McVittie authored
g_spawn_check_exit_status() was renamed to g_spawn_check_wait_status() in GLib 2.70 because its name was misleading: the first argument was always a wait-status (the output of wait(), waitpid() or waitid(), encoding either an exit status or a terminating signal) rather than an exit status. Use the modern name in our code. When building for scout or continue to provide our own implementation; when building for anything else older than GLib 2.70, provide a macro to wrap the old, misleading name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 06, 2021
-
-
Simon McVittie authored
PreloadModule is no longer used in pv-adverb, because we needed a different data structure there. Do a similar transformation here. This turns it inside out: instead of what's conceptually map<variable=LD_AUDIT or LD_PRELOAD, values=array<string>> we now have array<struct<variable=LD_AUDIT or LD_PRELOAD, string>> which is a bit easier to deal with in practice. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 03, 2021
-
-
Simon McVittie authored
I think this makes it a bit clearer what's going on: we populate one list (currently a PreloadModule[]) from the command-line options, then translate it to form a second list (in -wrap it's a plain GPtrArray, in -adverb it's implicit in the environment variables we're setting). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 20, 2021
-
-
When a game is launched with the Steam Overlay feature enabled (it's on by default), we end up with an LD_PRELOAD that contains `gameoverlayrenderer.so` two times, one for 32-bit and the other for 64-bit processes. However this leads to a warning that is harmless but scary for users and developers unaware of that: `ERROR: ld.so: object '/home/me/.local/share/steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.` And every 64-bit process prints something similar about the ELFCLASS32. By creating a temporary directory and using the dynamic linker token expansion `$PLATFORM` we can let a process preload only the `gameoverlayrenderer.so` for the right ABI. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- May 20, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- May 12, 2021
-
-
Simon McVittie authored
This function was originally written for pressure-vessel and subsequently added to Flatpak. If we use Flatpak's version, we can stay closer to being in sync with Flatpak's flatpak-utils.c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 22, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 26, 2021
-
-
Simon McVittie authored
These indicate which lines are harmless and which lines are really bad, without taking up too much space. The mapping from GLib log level to message is not 100% obvious, because G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen" situations (assertion failures, etc.) as "Internal error". Ideally, users should never see these: they indicate a bug. For situations that will cause pressure-vessel to exit with an error, introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the apt-style "E:" prefix. pv_log_failure() is a convenience macro to log at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but it's a fatal error prompted by something external to pressure-vessel, for which we want pressure-vessel to clean up "nicely" and exit gracefully, even though it's going to fail - so we can't use g_error() for this. In the parts of main() that involve parsing command-line arguments, add usage_error() as syntactic sugar for pv_log_failure(). I might eventually turn these into G_OPTION_ERROR_FAILED as we factor out more of main() into helper functions, but for now they're handled separately. For less-severe log levels, use single-letter prefixes similar to apt's. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 25, 2021
-
-
Ludovico de Nittis authored
This allows us to reduce the code duplication in pv_bwrap_run_sync(). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 23, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 13, 2021
-
-
Simon McVittie authored
Previously, pv_capture_output() always inherited pressure-vessel-wrap's own environment, and bwrap->envp was ignored. Thanks to @mawww on Github for spotting this. Fixes: f584a55c "runtime: Don't assume container's env is in the PATH" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 05, 2021
-
-
Ludovico de Nittis authored
This is especially useful when we are logging to a file to keep track of when a specific operation happened. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This is the middle ground between the base logging and the verbose option. Currently we are not logging any messages at the info level, but we might start to do that. And this option gives us more granularity about how much logging we want to print. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Moving this log function to "utils" allows us to avoid a lot of duplication. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@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
Because we were testing for a prefix match with a trailing slash, when FlatpakExports exports /home/me, we would not rewrite it to /home/me/.var/app/com.valvesoftware.Steam. Instead of adding the necessary special cases, use a slightly refactored version of flatpak_has_path_prefix(), which already does what we need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-