Skip to content
Snippets Groups Projects
  1. Jun 17, 2020
    • 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
  2. Jun 12, 2020
  3. May 21, 2020
  4. Apr 08, 2020
    • Simon McVittie's avatar
      wrap: Add the ability to unshare the pid namespace · feb948ed
      Simon McVittie authored
      This improves isolation between the host system and the game, and can
      be used in conjunction with bwrap's init/reaper process to make game
      termination fully reliable (unlike subreapers, killing the init process
      automatically kills the entire pid namespace).
      
      One major down-side of doing this is that if the game uses
      process-ID-oriented APIs, for example older versions of
      <https://github.com/FeralInteractive/gamemode
      
      >, then they will not
      work, because the process ID inside the container is not the same as
      the process ID outside the container.
      
      Unfortunately, Steam's own tracking of the processes that belong to a game
      is one of the process-ID-oriented APIs that this harms, so this branch
      does not unshare the pid namespace by default, only when requested. We
      can use this to test whether it can be done without breaking Steam;
      We will probably need to cope with separate pid namespaces if we create
      new containers from inside a Flatpak environment.
      
      Also add an option to unload the gameoverlayrenderer.so module, which
      is not acceptable for production use, but at least works around this
      well enough to unblock further testing.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      feb948ed
  5. Mar 04, 2020
  6. Feb 26, 2020
  7. Feb 17, 2020
  8. Feb 10, 2020
  9. Feb 03, 2020
  10. Jan 23, 2020
  11. Jan 06, 2020
  12. Dec 13, 2019
    • Simon McVittie's avatar
      wrap: Mount pressure-vessel on /run/pressure-vessel if using runtime · 596e50ad
      Simon McVittie authored
      When we're using a non-trivial runtime, we need to make
      pressure-vessel-with-lock available to the container.
      
      Previously, if your pressure-vessel installation was visible via your
      home directory (if shared), via $(realpath ~/.steam/steam), or via the
      current working directory at the time of running pressure-vessel-wrap,
      then it would exist in the container at the same path as outside the
      container, so this would work. However, if you have installed it in
      an alternative Steam library such as /media/big/library, none of these
      mount points would make it visible and bwrap would fail to run it.
      
      Circumvent this by mounting the relocatable pressure-vessel prefix
      on /run/pressure-vessel, which lets us run it via that path.
      
      Bug: https://github.com/ValveSoftware/steam-runtime/issues/204
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      596e50ad
  13. Nov 14, 2019
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      wrap: Take out a lock on the container's runtime for the duration · 959fd338
      Simon McVittie authored
      
      If we upgrade from runtime 0.20191024.0 to 0.20191108.0 while an app
      or game is still running under runtime 0.20191024.0, then deleting
      the app or game's shared libraries out from under it will probably
      break it.
      
      Flatpak solves this problem with a read/write lock on the file
      `files/.ref` - for runtimes this is `/usr/.ref` in the container.
      Each instance of `flatpak run` takes a read-lock on that file. Any
      number of processes can hold a read-lock at the same time.
      Before a package-manager-style operation like `flatpak uninstall`
      does anything destructive to a runtime, it takes a write-lock, which
      only succeeds if there are currently no read- or write-locks.
      Depending on the operation, the lock is either taken directly or by
      asking bubblewrap to do it.
      
      We'll use the same scheme. Different families of locking APIs interact
      unpredictably, so it's important that we use the same locking API as
      bubblewrap, namely POSIX byte-range (record) advisory locks via
      fcntl F_SETLK. In particular, this means flock(1) and flock(2) are
      not going to help us: they use POSIX file-level advisory locks.
      
      One difference between our locking and flatpak's is that we support
      runtimes that are not "merged /usr". In this case, we could either
      take a lock on files/.ref (/.ref in the container) or on files/usr/.ref
      (/usr/.ref in the container). I've chosen to do the former here, so that
      it's always files/.ref. It doesn't matter, as long as we're consistent.
      
      (For apps the lock file is `/app/.ref` and for extensions it's
      `$mountpoint/.ref`, but pressure-vessel doesn't have an equivalent of
      Flatpak apps or extensions yet.)
      
      This version is only a partial solution. We can't use bwrap --lock-file
      or bwrap --sync-fd without also using --unshare-pid, which breaks
      gameoverlayrenderer.so; so we do the next best thing, by leaking the
      lock fd to the bubblewrap process, which will leak it to the game's
      main process. This won't work if the game forks background processes,
      but it's good enough for a straightforward execve() chain.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      959fd338
    • Simon McVittie's avatar
      wrap: Print version number as YAML · d165c4d4
      Simon McVittie authored
      
      This is inspired by `ostree --version` and `docker version`.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d165c4d4
    • Simon McVittie's avatar
      wrap: Make GOptionEntry flags clearer · 04b440d1
      Simon McVittie authored
      
      Instead of {0, 0}, represent the absence of a short option with '\0'
      and the absence of flags with G_OPTION_FLAG_NONE. To support older GLib,
      provide a compatibility definition for the latter.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      04b440d1
  14. Nov 12, 2019
  15. Nov 11, 2019
  16. Sep 27, 2019
    • Simon McVittie's avatar
      wrap: Include all known NVIDIA libraries, except for libnvidia-gtk* · eec5cfd5
      Simon McVittie authored
      
      The NVIDIA proprietary EGL, GLES and Vulkan ICDs depend on
      libnvidia-eglcore and libnvidia-glvkspirv, but do not have DT_NEEDED
      entries for them (presumably they dlopen() them instead).
      capsule-capture-libs can only follow DT_NEEDED entries, so we have to
      special-case those hidden dependencies.
      
      Ideally we'd have a syntax for "libnvidia-*.so.* except libnvidia-gtk*",
      but currently we don't, so just include all the known libraries.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      eec5cfd5
  17. Sep 26, 2019
  18. Sep 25, 2019
  19. Sep 24, 2019
Loading