1. 17 May, 2019 2 commits
  2. 13 May, 2019 3 commits
    • Simon McVittie's avatar
      Update NEWS · 74e1cfab
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      74e1cfab
    • 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
    • Clemens Lang's avatar
      cmake: Avoid overwriting PKG_CONFIG_PATH env var · 6e432ed5
      Clemens Lang authored
      The CMake config file installed by DBus will run in the context of other
      projects. Consequently, changing the value of the PKG_CONFIG_DIR,
      PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR environment variables will affect
      any further calls to pkg-config made by such projects, which can cause
      problems.
      
      A common case of this happening are pkg-config files installed in
      usr/share/pkgconfig for .pc files that are architecture-independent, as
      for example systemd does.
      
      Avoid clobbering the environment variables by saving and restoring their
      values. Note that for some of the variables, setting them to an empty
      string is different from not setting them at all.
      Signed-off-by: 's avatarClemens Lang <clemens.lang@bmw-carit.de>
      (cherry picked from commit 3525cc04)
      Closes: #267
      6e432ed5
  3. 18 Apr, 2019 2 commits
  4. 17 Apr, 2019 7 commits
  5. 21 Jan, 2019 1 commit
    • Simon McVittie's avatar
      configure.ac: Forbid AX_-prefixed patterns more selectively · 6ef67cff
      Simon McVittie authored
      We want to make autoconf fail early and with a user-comprehensible
      message if autoconf-archive isn't installed, rather than generating
      a configure script with syntax errors, or a configure script that runs
      successfully but doesn't do what we intended.
      
      However, autoconf-archive doesn't actually guarantee not to use
      AX_-prefixed shell variable names without m4_pattern_allow'ing them
      (unlike Autoconf, Automake, Libtool and pkg-config, which explicitly use
      m4_pattern_allow for variables with AC_, AM_, LT_ and PKG_ prefixes), so
      it isn't safe to assume that they won't be used. In particular, recent
      versions of AX_CHECK_GNU_MAKE appear to be using
      $AX_CHECK_GNU_MAKE_HEADLINE as a shell variable.
      
      Instead, specifically forbid the names of the finite list of macros
      that we actually use.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Resolves: #249
      (cherry picked from commit ee09cc0a)
      6ef67cff
  6. 04 Dec, 2018 13 commits
  7. 03 Dec, 2018 3 commits
  8. 16 Nov, 2018 3 commits
    • Simon McVittie's avatar
      Update NEWS · a6bae612
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      a6bae612
    • Simon McVittie's avatar
      dbus-daemon test: Allow much longer for pending fd timeout · ffa3bc17
      Simon McVittie authored
      The timeout we're using here is 0.5s (500ms), but the actual time taken
      is unbounded, because the OS scheduler might not schedule our process
      for an arbitrary length of time after we become runnable.
      
      We previously allowed up to 1 second, but in the CI jobs for !9
      and !18 we've seen this take up to 3.4 seconds (presumably
      because other tests, or other jobs running on the same shared
      infrastructure, starved this process). Allow up to 10 seconds to guard
      against spurious failures.
      
      The timeout used in the production system.conf is 150 seconds (2½
      minutes), and we're only using the shorter 500ms timeout here to make
      the test complete more quickly, so ±10 seconds is relatively
      insignificant: the main thing is that it's finite.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 20e6eb7c)
      ffa3bc17
    • 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
  9. 05 Oct, 2018 1 commit
  10. 04 Oct, 2018 5 commits