Skip to content
Snippets Groups Projects
  1. Jan 23, 2024
  2. Jan 19, 2024
  3. Jan 15, 2024
  4. Jan 12, 2024
  5. Jan 05, 2024
  6. Jan 04, 2024
  7. Jan 03, 2024
  8. Dec 14, 2023
    • Simon McVittie's avatar
      Merge branch 'wip/task370' into 'main' · 742a60f7
      Simon McVittie authored
      pv-wrap: Don't register stdout, stderr, --pass-fd with FlatpakBwrap
      
      See merge request !640
      742a60f7
    • Simon McVittie's avatar
      pv-wrap: Don't register stdout, stderr, --pass-fd with FlatpakBwrap · 8ee66f4c
      Simon McVittie authored
      
      This fixes two separate issues.
      
      If we add a file descriptor to the FlatpakBwrap object with
      flatpak_bwrap_add_fd, then flatpak_bwrap_child_setup() will lseek()
      back to byte 0 before it execs the replacement process. This is
      often what we want - for example, when we have written out a file
      containing the container identification, we want any subsequent
      read from that file to start at byte 0.
      
      However, it is absolutely not what we want if stdout/stderr are directed
      to a log file, in which case any writes after the lseek() will start from
      the beginning and overwrite the content of the log file. The symptom for
      this is that debug messages from pv-adverb start at the beginning of the
      log file, overwriting earlier debug messages from pv-wrap (but directing
      the log to a pipe or to the systemd Journal works fine, because those
      aren't seekable). Similarly, if --pass-fd is being used for a seekable
      file, we probably don't want to force it to seek back to byte 0.
      
      The second issue is that adding a fd with flatpak_bwrap_add_fd()
      means the FlatpakBwrap object takes responsibility for closing that
      fd. This was incorrect to do for original_stdout and original_stderr
      without transferring ownership (which we don't want to do), because
      they are declared with glnx_autofd, meaning that they will be closed
      automatically when they go out of scope. In the error code path where
      pv_bwrap_execve() fails, this means they will be closed twice - once
      by glnx_autofd, and once by the g_autoptr(FlatpakBwrap) - leading to
      an assertion failure. This is mitigated by not being a problem in the
      success code path where pv_bwrap_execve() succeeds, which in practice
      is the one we always want to reach.
      
      Avoid both of these by using a separate list of fds to inherit, not
      seeking back to the beginning of those, and not closing them.
      
      This has the side-effect that fds from --pass-fd are also not closed,
      but that seems harmless, and arguably more correct: they're open on
      entry to main(), and they're still open on exit from main(), so no
      change of ownership has happened.
      
      steamrt/tasks#370
      
      Fixes: 779d13fd "pv-wrap: Let pv-adverb restore our original stdout/stderr"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      8ee66f4c
  9. Dec 13, 2023
  10. Dec 08, 2023
Loading