1. 13 May, 2019 1 commit
    • Simon McVittie's avatar
      bus: Try to raise soft fd limit to match hard limit · 94bacc69
      Simon McVittie authored
      Linux systems have traditionally set the soft limit to 1024 and the hard
      limit to 4096. Recent versions of systemd keep the soft fd limit at
      1024 to avoid breaking programs that still use select(), but raise the
      hard limit to 512*1024, while in recent Debian versions a complicated
      interaction between components gives a soft limit of 1024 and a hard
      limit of 1024*1024. If we can, we might as well elevate our soft limit
      to match the hard limit, minimizing the chance that we will run out of
      file descriptor slots.
      
      Unlike the previous code to raise the hard and soft limits to at least
      65536, we do this even if we don't have privileges: privileges are
      unnecessary to raise the soft limit up to the hard limit.
      
      If we *do* have privileges, we also continue to raise the hard and soft
      limits to at least 65536 if they weren't already that high, making
      it harder to carry out a denial of service attack on the system bus on
      systems that use the traditional limit (CVE-2014-7824).
      
      As was previously the case on the system bus, we'll drop the limits back
      to our initial limits before we execute a subprocess for traditional
      (non-systemd) activation, if enabled.
      
      systemd activation doesn't involve us starting subprocesses at all,
      so in both cases activated services will still inherit the same limits
      they did previously.
      
      This change also fixes a bug when the hard limit is very large but
      the soft limit is not, for example seen as a regression when upgrading
      to systemd >= 240 (Debian #928877). In such environments, dbus-daemon
      would previously have changed its fd limit to 64K soft/64K hard. Because
      this hard limit is less than its original hard limit, it was unable to
      restore its original hard limit as intended when carrying out traditional
      activation, leaving activated subprocesses with unintended limits (while
      logging a warning).
      Reviewed-by: Lennart Poettering's avatarLennart Poettering <lennart@poettering.net>
      [smcv: Correct a comment based on Lennart's review, reword commit message]
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 7eacbfec)
      [smcv: Mention that this also fixes Debian #928877]
      94bacc69
  2. 17 Apr, 2019 2 commits
  3. 04 Dec, 2018 2 commits
  4. 16 Nov, 2018 1 commit
    • Simon McVittie's avatar
      build: Never use poll() on Darwin family (macOS, etc.) or Interix · 6cb51b22
      Simon McVittie authored
      Doing a runtime check in configure.ac (AC_RUN_IFELSE) has several
      disadvantages:
      
      * It doesn't work when cross-compiling. For example, if we build macOS
        binaries on a Linux system, we'd assume that poll() works, but in
        fact it won't.
      
      * It checks the build system capabilities, but that is not necessarily
        appropriate if (for example) a macOS 10.10 user builds binaries that
        could be used by macOS 10.12 or macOS 10.9 users.
      
      * It checks for one specific failure mode, but macOS seems to have a
        history of various implementation issues in poll().
      
      * If we want it to work in CMake, we have to duplicate it in the CMake
        build system.
      
      None of these is a showstopper on its own, but the combination of all
      of them makes the current approach to avoiding the broken poll() on
      macOS look unreliable. libcurl, a widely-portable library making
      extensive use of sockets, specifically doesn't use poll() on Darwin
      (macOS, iOS, etc.) or on Interix; let's follow their example here.
      
      See also https://bugzilla.gnome.org/show_bug.cgi?id=302672 and
      https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
      for some relevant history.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Resolves: #232
      (cherry picked from commit 0414ea65)
      6cb51b22
  5. 04 Oct, 2018 2 commits
  6. 30 Aug, 2018 1 commit
  7. 29 Aug, 2018 1 commit
  8. 02 Aug, 2018 4 commits
  9. 04 Jun, 2018 1 commit
  10. 06 Feb, 2018 3 commits
  11. 27 Nov, 2017 1 commit
    • Simon McVittie's avatar
      _dbus_server_new_for_socket: Iterate over arrays as intended · 9a842883
      Simon McVittie authored
      Commit 0c03b505 was meant to clear all the fds indexed by j in
      [0, n_fds), which socket_disconnect() can't be allowed to close
      (because on failure the caller remains responsible for closing them);
      but instead it closed the one we failed to add to the main loop
      (fd i), repeatedly.
      
      Similarly, it was meant to invalidate all the watches indexed by j
      in [i, n_fds) (the one we failed to add to the main loop and the ones
      we didn't try to add to the main loop yet), which socket_disconnect()
      can't be allowed to see (because it would fail to remove them from
      the main loop and hit an assertion failure); but instead it invalidated
      fd i, repeatedly.
      
      These happen to be the same thing if you only have one fd, resulting
      in the test-case passing on an IPv4-only system, but failing on a
      system with both IPv4 and IPv6.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      (cherry picked from commit c9aa00ce)
      9a842883
  12. 24 Nov, 2017 3 commits
  13. 07 Nov, 2017 3 commits
  14. 23 Oct, 2017 1 commit
  15. 18 Oct, 2017 1 commit
  16. 17 Oct, 2017 1 commit
  17. 09 Oct, 2017 1 commit
  18. 29 Sep, 2017 1 commit
  19. 28 Sep, 2017 4 commits
  20. 27 Sep, 2017 2 commits
  21. 25 Sep, 2017 2 commits
  22. 15 Aug, 2017 2 commits