Skip to content
Snippets Groups Projects
  1. Feb 26, 2020
  2. Feb 25, 2020
  3. Feb 19, 2020
  4. Feb 17, 2020
  5. Feb 10, 2020
  6. Feb 03, 2020
  7. Jan 23, 2020
  8. Jan 08, 2020
  9. Jan 07, 2020
  10. 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
    • Simon McVittie's avatar
      bwrap-lock: Add support for OFD locks · 4ad7b057
      Simon McVittie authored
      
      These more modern locks, introduced in Linux 3.15 and not yet included
      in POSIX, propagate across fork(), dup(), fd-passing etc. the way you'd
      expect: as long as at least one copy of the inherited or fd-passed file
      descriptor remains open, the lock remains held. This allows us to
      pass a lock fd to a child process across bwrap's fork-and-exec the way
      we were already trying to, and have it actually work.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      4ad7b057
Loading