Skip to content
Snippets Groups Projects
  1. Sep 02, 2020
  2. 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
  3. Jul 29, 2020
  4. May 21, 2020
  5. Mar 04, 2020
  6. Feb 26, 2020
    • Simon McVittie's avatar
      bwrap: Don't create a /libexec symlink · 8ba50039
      Simon McVittie authored
      
      We want all the libQUAL directories, including lib32 and lib64 (and in
      principle also libx32, libn32 etc.), but we specifically don't care
      about libexec. Real systems don't usually symlink /usr/libexec into the
      root directory.
      
      If we create a /libexec symlink, the only effect it might have is that
      game developers start relying on it, which we certainly don't want.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      8ba50039
  7. Jan 06, 2020
    • Simon McVittie's avatar
      wrap: Tell child process to take out its own lock if necessary · d47b241c
      Simon McVittie authored
      
      Non-OFD locks don't propagate across fork(), and bwrap needs to clone()
      itself (which behaves like fork() in this respect) to separate itself
      into a parent outside the container and a child inside the container.
      
      This change adds a weak dependency on Linux 3.15. If we run on an older
      version, everything should still *work*, but there will be a short
      period of time during which we have already decided to use the runtime,
      but it is not locked (and in particular not protected from deletion).
      
      Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d47b241c
  8. Nov 12, 2019
  9. Sep 11, 2019
  10. Sep 10, 2019
  11. Sep 04, 2019
Loading