- Jun 23, 2020
-
-
Simon McVittie authored
Because we do a "cheap copy" with hard-links where possible, .ref is a hard-link to its counterpart in the original (non-copied) runtime, so a lock on one is a lock on the other. We hold a lock on the original runtime while we do setup, so we would never actually delete the temporary runtimes unless we break the hard-link by re-creating the lock file. Resolves: T22035 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Prioritize "/usr/" over "/lib/" if it is available to avoid issues when we use a non merged-/usr container with a host system that is merged-/usr (Fixes: T22125) Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 17, 2020
-
-
Simon McVittie authored
Flatpak is not going to give us control over the root directory when using sub-sandboxing - the most we're likely to get is control over which directory is chosen to be /usr. Prepare for this by using /usr/lib/pressure-vessel/overrides instead of /overrides for the things we overwrite. To be nice to developers and steam-runtime-tools, put a symlink overrides -> usr/lib/pressure-vessel/overrides at the root, as a hint for where to look. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a mutable sysroot, overwrite ld.so with a symlink into /run/host. We overwrite both the interoperable path (to avoid long chains of symlinks in the common case) and the canonicalized path (to make sure nothing can end up finding the container's ld.so, which is incompatible with the libc we have dropped in). If building a long bwrap command-line, we have to mount over the canonicalized path, and just live with the fact that there will be a long chain of symlinks leading to it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We currently arrange for the overridden libraries to be used by setting the LD_LIBRARY_PATH, but this fails in two cases: - If we want to use the scout LD_LIBRARY_PATH Steam Runtime inside a newer container (approximating how Steam games currently run in practice), it will reset the LD_LIBRARY_PATH instead of prepending to it. - Games also sometimes overwrite the LD_LIBRARY_PATH instead of prepending to it. We can avoid all that by arranging for our directories in /overrides to be in the default search path for ld.so, by editing ld.so.conf and running ldconfig, like Flatpak does (T14481). However, if we do that, we cannot reliably force a resolution order: ldconfig considers the OS ABI tag, which exists on some libraries and in particular on the versions of glibc and Mesa in scout, to be more important than directory search order. See also: https://bugs.freedesktop.org/show_bug.cgi?id=26663 If we don't remove the unwanted version of glibc, we also run the risk of encountering mismatched copies of glibc and ld.so, leading to an immediate crash. This is particularly likely to happen if we use bwrap to enter the partially-set-up container. Because we have a temporary mutable copy of the sysroot, we can solve this easily by deleting the overridden libraries. That way, there can be no confusion: the only remaining implementation of each SONAME is the one we wanted :-) Note that after removing the overridden libraries, we will be unable to execute code in the sysroot without mounting /overrides/lib and setting up the LD_LIBRARY_PATH to point into it: for example, in the common case where we have taken libc from the host, the mutable sysroot no longer contains libc.so.6. This is why it's so important that a previous commit avoided the call to readlink(1) inside the container for the mutable case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we have a mutable copy of the sysroot (which we know is a complete sysroot, not just /usr), then we don't need to use bwrap to rearrange it into something where we can canonicalize a path. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This no longer needs to be read/write, because we make all the changes we are going to make during setup. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we don't need to alter the PATH in the runtime. If we're using a mutable runtime, we'll delete the version in the runtime and replace it with a symlink to /run/host/usr/bin/locale or similar; if not, we'll bind-mount the host /usr/bin/locale onto it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because that isn't going to work if you have EGL/Vulkan ICDs installed in your home directory or something, and the JSON file is small, we fall back to copying in this case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Feature parity with the existing code requires that we check for a compatible container: in containers where /usr/share/libdrm is not a directory, this won't work. Beef up the compatibility check a bit so that it checks for directory vs. non-directory generically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We only strictly need pressure-vessel-with-lock and GLib (and we could skip even the GLib dependency if we assume the runtime contains GLib >= 2.32, as all ours do), but the relocatable copy is designed to be portable to any OS, so for now let's copy the whole thing in. When we do it like this, it's in /usr, because we anticipate that Flatpak sub-sandboxing is not going to give us control over /run. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Flatpak sub-sandboxing won't let us bind-mount arbitrary things over arbitrary locations, but if we have a mutable copy of the runtime, we can delete runtime content and replace it with host system equivalents. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're about to start editing the mutable runtime in-place to replace files we don't want with symlinks to /run/host, but if /run/host isn't mounted then that can't work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Even in the case where we're using a temporary directory, it's going to survive at least as long as the call to locale-gen, so we don't need to translate it into a long series of --dir and --symlink directives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we're able to inspect it in --only-prepare mode. At the moment we still create /overrides/bin/localedef, /overrides/bin/locale, and sometimes EGL and Vulkan JSON via --symlink or --ro-bind, so we have to make /overrides read/write from the perspective of the container. However, when we have moved to creating those files as symlinks in /overrides, we will be able to lock it down to read-only from the perspective of the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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 16, 2020
-
-
Simon McVittie authored
This will be used to delete libraries from the runtime if their SONAME is the same as a library that we brought in from outside, to avoid conflicts when precedence gets mixed up. A manual test is included. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This gives us a way to traverse paths in the sysroot, without accidentally following a symbolic link that leads outside. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we're running locale-gen on the host system, we might as well just run it, without wrapping bwrap around it. This requires the new --output-dir option in p-v-locale-gen. To stay consistent, also move from bwrap --chdir DIR to p-v-locale-gen --output-dir DIR in the case where we still need to use bwrap. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the runtime is already "the right shape", then we don't need to use bwrap to mount it on /usr and populate a suitable tmpfs root filesystem. We need to do this if we want to support being run from inside a Flatpak, because we can't run bwrap inside Flatpak. It might also speed up accesses to suitable runtimes, because we won't waste time invoking extra bwrap processes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
flatpak_canonicalize_filename() only does a syntactic normalization, eliminating ./ and similar constructs; it does not resolve symbolic links. We need to use the realpath() of the 64-bit dynamic linker, because otherwise, when we start replacing the dynamic linker in the container with a symlink into /run/host, the host system might have a symlink /lib64/ld-linux-x86-64.so.2 pointing outside /lib64, for example to /lib/ld-linux-x86-64-2.30.so. Then we'd get: runtime's ld-linux-x86-64.so.2 -> /run/host/lib64/ld-linux-x86-64.so.2 -> /lib/ld-linux-x86-64-2.30.so -> does not necessarily exist inside container Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As noted in the comment, the order matters. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This was using bwrap to make ${libdir}/dri available on /run/host/${libdir}/dri, in order to run the equivalent of: ln -fns /run/host/${libdir}/dri/* /overrides/lib/${tuple}/dri/ Instead of using the shell wildcard '*' to implement readdir(), let's just call readdir(${libdir}/dri) ourselves, and fix up the symlink targets to point into /run/host/${libdir}/dri. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The PATH from outside the container doesn't really make sense inside the container, because the directory hierarchy could be totally different (particularly on unusual host systems like GoboLinux and Exherbo). Resetting it also makes sure we don't pick up local installations in ~/bin or ~/.local/bin, which could have dependencies that are unsatisfied in the container. Conversely, the PATH from the host might not include everything we need in the container. If the host system is an OS that only supports merged-/usr use, like Arch Linux, then it might not have both /usr/bin and /bin in the PATH - but if the container is not merged /usr, like a scout SDK sysroot, then we'll need both. This approximately matches Flatpak's behaviour: by default it resets PATH to /app/bin:/usr/bin (because it puts app-specific content in /app and can assume that its runtimes are always merged-/usr). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 12, 2020
-
-
Simon McVittie authored
This lets us hold a fd to the parent directory open and resolve paths relative to it (see openat(2)). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
At some point while I was designing this, the @path was a directory, but it ended up being a file. Fixes: 8b531350 "wrap: Add API for a bubblewrap-compatible fcntl lock" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Rather than saying "but what if they are on different filesystems?" we might as well just make it work optimally fast either way, since the author of libglnx has already done the hard part for us. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It isn't particularly important either way, but there's no real reason not to. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Using only the 0th slot doesn't actually save us any memory, and being consistent about what the slots mean will make it easier to factor out common code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we failed to bind the driver into the container, then we don't want to try to use it later. 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>
-