Skip to content
Snippets Groups Projects
  1. 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
  2. Jun 12, 2020
  3. May 21, 2020
  4. May 20, 2020
  5. May 18, 2020
  6. Apr 15, 2020
  7. Apr 09, 2020
  8. 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
  9. Mar 24, 2020
Loading