Skip to content
Snippets Groups Projects
  1. Sep 03, 2020
  2. 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
  3. Aug 20, 2020
  4. Aug 19, 2020
  5. 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
  6. Aug 11, 2020
  7. Jul 29, 2020
  8. Jul 21, 2020
  9. Jul 09, 2020
  10. Jul 08, 2020
  11. Jun 23, 2020
  12. 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
  13. Jun 16, 2020
Loading