Skip to content
Snippets Groups Projects
  1. Sep 04, 2020
  2. Sep 02, 2020
  3. Sep 01, 2020
    • Simon McVittie's avatar
      wrap: Don't populate environment of FlatpakBwrap that will be merged · 07f02a83
      Simon McVittie authored
      
      The default for a FlatpakBwrap object is to copy the calling
      environment as a base for the environment that it will build up.
      However, that's wrong if we are going to merge more than one
      FlatpakBwrap together: the merged FlatpakBwrap's argv will be appended
      to the destination FlatpakBwrap, but the merged envp will overwrite the
      corresponding variables in the destination.
      
      Avoid this by making sure that every time we merge two FlatpakBwrap
      objects, one of them has an empty environment.
      
      Resolves: T23422
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      07f02a83
  4. Aug 19, 2020
  5. Aug 18, 2020
    • Simon McVittie's avatar
      adverb, wrap: Implement --exit-with-parent · 0241a714
      Simon McVittie authored
      
      -wrap eventually replaces itself with bubblewrap. If the bubblewrap
      process is killed, we want the adverb command to be terminated, passing
      the termination signal on to its own child process.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0241a714
    • 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 31, 2020
  8. Jul 29, 2020
  9. Jul 21, 2020
  10. Jul 02, 2020
  11. 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
  12. Jun 12, 2020
  13. May 21, 2020
  14. 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
  15. Mar 04, 2020
  16. Feb 26, 2020
Loading