1. 11 Dec, 2017 1 commit
  2. 29 Sep, 2017 2 commits
  3. 30 Jun, 2017 1 commit
    • Simon McVittie's avatar
      build: Introduce ${runstatedir} and use it for the pid file · 1477ca50
      Simon McVittie authored
      By default ${runstatedir} is the same as ${localstatedir}/run, but many
      Linux distributions configure it to be /run and mount a tmpfs in that
      location. All other factors being equal, it is preferable to use /run
      where available because it is guaranteed to be local, whereas traversing
      /var might involve automounting a networked filesystem (even though
      /var/run itself is very likely to be a tmpfs).
      /run or /var/run is currently only used in a few places in dbus, but
      I plan to make more use of it during the development of
      The pid file is not part of the API between dbus and other software
      (other than distribution init scripts for dbus itself), so we do not
      need to keep it strictly compatible; so it is OK to move it.
      We do not yet use /run for the system bus socket, because that is
      part of the API between D-Bus clients and servers, and has always been
      "officially" /var/run/dbus/system_bus_socket.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
      possibility of changing that.
      Similarly, we do not replace /var/run/console with /run/console, because
      that path is part of the API between dbus-daemon and the obsolete PAM
      modules pam_console and pam_foreground that used /var/run/console.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
      future removal of that code path.
      In the CMake build system, the equivalent of ${runstatedir} remains
      hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
      the sort of system-wide installations that would consider redefining
      ${runstatedir} to /run, the Autotools build system is strongly
      recommended: in particular this is what Linux distributions are expected
      to use.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
  4. 18 Apr, 2017 1 commit
  5. 13 Oct, 2016 1 commit
  6. 12 Feb, 2016 2 commits
  7. 11 Feb, 2016 1 commit
  8. 05 Mar, 2015 1 commit
  9. 03 Mar, 2015 1 commit
  10. 12 Feb, 2015 1 commit
  11. 04 Feb, 2015 1 commit
  12. 05 Jan, 2015 1 commit
  13. 24 Oct, 2014 1 commit
  14. 17 Oct, 2014 1 commit
  15. 15 Sep, 2014 1 commit
    • Simon McVittie's avatar
      config: change DEFAULT_MESSAGE_UNIX_FDS to 16 · 6465e37c
      Simon McVittie authored
      This addresses CVE-2014-3636.
      Based on a patch by Alban Crequy. Now that it's the same on all
      platforms, there's little point in it being set by configure/cmake.
      This change fixes two distinct denials of service:
      fd.o#82820, part A
      Before this patch, the system bus had the following default configuration:
      - max_connections_per_user: 256
      - DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176)
        as defined by configure.ac
      - max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
      - max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
      - max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024
      This means that a single user could create 256 connections and transmit
      256*4096 = 1048576 file descriptors.
      The file descriptors stay attached to the dbus-daemon process while they are
      in the message loader, in the outgoing queue or waiting to be dispatched before
      D-Bus activation.
      dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the
      limit is reached and dbus-daemon needs to receive a message with a file
      descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC.
      Dbus-daemon cannot recover from that error because the kernel does not have any
      API to retrieve a file descriptor which has been discarded with MSG_CTRUNC.
      Therefore, it closes the connection of the sender. This is not necessarily the
      connection which generated the most file descriptors so it can lead to
      denial-of-service attacks.
      In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to
      max_connections_per_user * max_incoming_unix_fds = 256 * 64 = 16384
      This is less than the usual "ulimit -n" (65536) with a good margin to
      accomodate the other sources of file descriptors (stdin/stdout/stderr,
      listening sockets, message loader, etc.).
      Distributors on non-Linux may need to configure a smaller limit in
      system.conf, if their limit on the number of fds is smaller than
      fd.o#82820, part B
      On Linux, it's not possible to send more than 253 fds in a single sendmsg()
      call: sendmsg() would return -EINVAL.
        #define SCM_MAX_FD      253
      SCM_MAX_FD changed value during Linux history:
      - it used to be (OPEN_MAX-1)
      - commit c09edd6eb (Jul 2007) changed it to 255
      - commit bba14de98 (Nov 2010) changed it to 253
      Libdbus always sends all of a message's fds, and the beginning
      of the message itself, in a single sendmsg() call. Combining these
      two, a malicious sender could split a message across two or more
      sendmsg() calls to construct a composite message with 254 or more
      fds. When dbus-daemon attempted to relay that message to its
      recipient in a single sendmsg() call, it would receive EINVAL,
      interpret that as a fatal socket error and disconnect the recipient,
      resulting in denial of service.
      This is fixed by keeping max_message_unix_fds <= SCM_MAX_FD.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820Reviewed-by: default avatarAlban Crequy <alban.crequy@collabora.co.uk>
  16. 27 Jan, 2014 1 commit
  17. 09 Jan, 2014 1 commit
  18. 08 Oct, 2013 1 commit
  19. 16 Sep, 2013 1 commit
    • Simon McVittie's avatar
      dbus-sysdeps-win: don't include wspiapi.h · 3b9c2817
      Simon McVittie authored
      This block provoked a warning on mingw-w64 because we were redefining
      _inline. According to Ralf's research, it was introduced in 452ff68a:
      Windows 2000 doesn't have getaddrinfo and related functions in
      ws2tcpip.h, but does have a shim implementation in wspiapi.h.
      At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
      why there was a __GNUC__ code path here. The "#define _inline" on that
      code path looks likely to be some sort of workaround for a faulty version
      of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
      __GNUC__ code path and get the redefinition.
      dbus no longer supports Windows 2000, so we no longer need wspiapi.h
      at all, and can rely on XP or later. (Ralf's policy is to only support
      versions of Windows that are still supported by Microsoft, and Windows 2000
      reached the end of its life-cycle in 2010.)
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
      Reviewed-by: Ralf Habacker
  20. 28 Aug, 2013 2 commits
  21. 28 Jun, 2013 2 commits
  22. 25 Jun, 2013 2 commits
  23. 18 Apr, 2013 2 commits
  24. 11 Apr, 2013 1 commit
    • Matt Fischer's avatar
      Set default maximum number of Unix fds according to OS · 97729354
      Matt Fischer authored
      QNX has an arbitrary limit to the number of file descriptors
      which may be passed in a message, which is smaller than the
      current default.  This patch therefore changes the default from
      a hardcoded constant to a macro, which is determined at configure
      time by looking at the host operating system.
      [This reduces the limit from 4096 (session)/1024 (system) to 128 fds
      per message on QNX, and 1024 fds per message on other operating systems.
      I think the reduced session bus limit on other OSs is a reasonable change
      too, given that the default hard/soft ulimits in Linux are only 4096/1024
      fds per process. -smcv]
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
      Reviewed-by: Simon McVittie <simon.mcvittie.collabora.co.uk>
  25. 13 Aug, 2012 2 commits
  26. 04 Jan, 2012 1 commit
    • Simon McVittie's avatar
      Revert all changes since a36d4918 · 5df8c3db
      Simon McVittie authored
      Someone seems to have merged part of master into 1.4. Again. Let's go
      back to the "last known good" point (the branch-point of some 1.4
      branches I had locally), then we can cherry-pick the changes that
      should have gone in.
  27. 28 Sep, 2011 2 commits
    • Simon McVittie's avatar
      Merge tests' cmake and autotools bus configuration · e9f0378b
      Simon McVittie authored
      In Unix, the tests listened on both debug-pipe (which is a socketpair,
      or a TCP emulation of socketpair on Windows) and a Unix socket.
      In the Windows port, the tests were hard-coded to listen on a particular
      port, which allowed the dispatch test to connect to that port, as long
      as no two tests ran simultaneously (which I don't think was ever guaranteed -
      make -j can violate this). That's valid out-of-process, and also
      fully-specified, so they only needed one <listen> directive, so the
      CMake input only had one.
      To make the tests work under CMake on Unix, there was a hack: the string
      substituted for the content of the <listen> directive contained
      </listen><listen> to get the other address in, which is pretty nasty.
      Instead of doing that, I've made both build systems, on both Unix and
      Windows, use both debug-pipe and a more normal transport (Unix or TCP).
      debug-pipe has a Windows implementation and it's used in
      dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
      hard-coded rather than being a configure parameter (there's no reason
      to vary it in different builds), and I used TEST_LISTEN as the name of the
      Unix/TCP address, because it's a "vague" address (no specific Unix path, no
      TCP port), that you can listen on but not connect to.
      This in turn means that we can merge the Autoconf .in and CMake .cmake
      files, similar to Bug #41033.
      You might wonder why I've kept debug-pipe. I did try to get rid of it, but
      it turns out that the tests in dispatch.c rely on
      dbus_connection_open_private() not blocking, and normal socket
      connections block on connect(). Until we fix that by adding an async
      version of dbus_connection_open_private(), it won't be safe to have a
      test like dispatch.c that "talks to itself", unless it uses a transport
      as trivial as debug-pipe in which neither end has to block on the other.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
    • Simon McVittie's avatar
      Simplify substitution of test executables to use fewer variables · 33c43947
      Simon McVittie authored
      Also use EXEEXT in all the service files, even in the automake build
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
  28. 13 Aug, 2011 1 commit
  29. 05 Aug, 2011 1 commit
    • Ralf Habacker's avatar
      Win32 compile fix. · b0b5f9b1
      Ralf Habacker authored
      msvc compilers define 'inline' only for c++ code, so wrap it
      with a platform independent DBUS_INLINE define in cmake
      generated config.h.
  30. 08 Jul, 2011 1 commit
  31. 01 Jul, 2011 1 commit
  32. 28 May, 2011 1 commit