Skip to content
Snippets Groups Projects
  1. Sep 02, 2020
    • Ludovico de Nittis's avatar
      Initial support for custom graphics provider path and Flatpak · d7ad67a2
      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: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      d7ad67a2
    • Ludovico de Nittis's avatar
      bwrap: Build arguments to bind /usr if already in a container · f81c2d57
      Ludovico de Nittis authored
      
      The filesystem that is providing /usr might not be mounted
      in the same place in the current namespace, and on the host
      system where bwrap will be run. If it isn't, we need
      to use one path to do file I/O when inspecting it, but pass
      a different path to bwrap.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      f81c2d57
  2. Aug 20, 2020
  3. Aug 19, 2020
  4. Aug 18, 2020
    • Simon McVittie's avatar
      runtime: Always provide adverb at /run/pressure-vessel/pv-from-host · 220657c6
      Simon McVittie authored
      
      While we control /run, we might as well be consistent.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      220657c6
    • Simon McVittie's avatar
      adverb, wrap: Add --terminate-timeout, --terminate-idle-timeout options · 18bdc4b9
      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: default avatarSimon McVittie <smcv@collabora.com>
      18bdc4b9
  5. Aug 11, 2020
  6. Jul 29, 2020
  7. Jul 21, 2020
  8. Jul 09, 2020
  9. Jul 08, 2020
  10. Jun 23, 2020
  11. Jun 17, 2020
    • Simon McVittie's avatar
      runtime: Move pressure-vessel overrides into /usr · e1439c1a
      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: default avatarSimon McVittie <smcv@collabora.com>
      e1439c1a
    • Simon McVittie's avatar
      runtime: Use pv_runtime_take_from_host() for ld.so · bf8396b5
      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: default avatarSimon McVittie <smcv@collabora.com>
      bf8396b5
    • Simon McVittie's avatar
      runtime: Remove overridden libraries from mutable sysroot · 5b403eb2
      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: default avatarSimon McVittie <smcv@collabora.com>
      5b403eb2
    • Simon McVittie's avatar
      runtime: Try to resolve path to ld.so without running bwrap · 6d6bb03b
      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: default avatarSimon McVittie <smcv@collabora.com>
      6d6bb03b
    • Simon McVittie's avatar
      runtime: Mount /overrides from mutable sysroot as read-only · e29d8a3c
      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: default avatarSimon McVittie <smcv@collabora.com>
      e29d8a3c
    • Simon McVittie's avatar
      runtime: Overwrite or over-mount localedef(1) and locale(1) · fcec146a
      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: default avatarSimon McVittie <smcv@collabora.com>
      fcec146a
    • Simon McVittie's avatar
      runtime: Create EGL, Vulkan ICD JSON as symlinks into /run/host · 9bd42167
      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: default avatarSimon McVittie <smcv@collabora.com>
      9bd42167
    • Simon McVittie's avatar
      runtime: Replace libdrm data with a symlink to host copy if necessary · 675f6565
      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: default avatarSimon McVittie <smcv@collabora.com>
      675f6565
    • Simon McVittie's avatar
      runtime: Copy pressure-vessel itself into mutable runtime if needed · ce063872
      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: default avatarSimon McVittie <smcv@collabora.com>
      ce063872
    • Simon McVittie's avatar
      runtime: Replace glibc-related data with symlinks into /run/host · 9cc0c933
      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: default avatarSimon McVittie <smcv@collabora.com>
      9cc0c933
    • Simon McVittie's avatar
      runtime: When entering runtime, always bind-mount /run/host · 6336748d
      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: default avatarSimon McVittie <smcv@collabora.com>
      6336748d
    • Simon McVittie's avatar
      runtime: Bind-mount /overrides to run locale-gen · 5e2f9f25
      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: default avatarSimon McVittie <smcv@collabora.com>
      5e2f9f25
    • Simon McVittie's avatar
      runtime: Create /overrides on disk if using a mutable sysroot · 9804c750
      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: default avatarSimon McVittie <smcv@collabora.com>
      9804c750
    • Simon McVittie's avatar
      runtime: Garbage-collect unused temporary runtimes · ee1bae76
      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: default avatarSimon McVittie <smcv@collabora.com>
      ee1bae76
    • Simon McVittie's avatar
      wrap: Add an --only-prepare mode · 3d79c339
      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: default avatarSimon McVittie <smcv@collabora.com>
      3d79c339
    • Simon McVittie's avatar
      runtime: Optionally copy the runtime, and bind-mount the copy · 66d41ccd
      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: default avatarSimon McVittie <smcv@collabora.com>
      66d41ccd
  12. Jun 16, 2020
    • Simon McVittie's avatar
      runtime: Don't use bwrap to run locale-gen when not required · a7741724
      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: default avatarSimon McVittie <smcv@collabora.com>
      a7741724
    • Simon McVittie's avatar
      runtime: Access runtime without using bwrap if possible · 135bea0b
      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: default avatarSimon McVittie <smcv@collabora.com>
      135bea0b
    • Simon McVittie's avatar
      runtime: Really use the realpath() of the host ld.so · d8cc2d35
      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: default avatarSimon McVittie <smcv@collabora.com>
      d8cc2d35
    • Simon McVittie's avatar
      6fdde58f
    • Simon McVittie's avatar
      runtime: Sort DRI "search path" more carefully · 623648fd
      Simon McVittie authored
      
      As noted in the comment, the order matters.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      623648fd
    • Simon McVittie's avatar
      runtime: Save a bwrap invocation and a shell by not using globbing · b51d3fd8
      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: default avatarSimon McVittie <smcv@collabora.com>
      b51d3fd8
    • Simon McVittie's avatar
      runtime: Reset PATH in the container · 3fea265c
      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: default avatarSimon McVittie <smcv@collabora.com>
      3fea265c
Loading