1. 15 Aug, 2017 1 commit
    • Lennart Poettering's avatar
      sysdeps: increase listen() backlog of AF_UNIX sockets to SOMAXCONN · a8dc1ebd
      Lennart Poettering authored
      Previously, the listen() backlog was set to an arbitrary 30. This means
      that if dbus-daemon is overloaded only 30 more connections may be queued
      by the kernel, before connect() fails with EAGAIN. (Note that EAGAIN !=
      EINPROGRESS -- the latter is what is returned if a connection is queued
      and being processed for asynchronous sockets; EAGAIN in this case is
      really an error, that cannot be recovered from).
      
      Most software simply sets SOMAXCONN as backlog for AF_UNIX sockets, to
      allow queuing of as many connections as the kernel allows. SOMAXCONN is
      128 on Linux, which is not particularly high, but at least higher than
      30.
      
      This patch changes dbus-daemon to do the same.
      
      I noticed this when flooding dbus-daemon with a lot of connections,
      where it pretty quickly ceased to respond, much earlier than it really
      should.
      
      Note that the backlog has nothing to do with the number of concurrent
      connections allowed, it simply controls how many queued, but not
      accept()ed connections there may be on the listening socket.
      
      (cherry picked from commit 12bd6e89)
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95264
      Bug-Debian: https://bugs.debian.org/872144Reviewed-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Thiago Macieira's avatarThiago Macieira <thiago@kde.org>
      a8dc1ebd
  2. 16 Feb, 2017 1 commit
    • Simon McVittie's avatar
      Change _dbus_create_directory to fail for existing directories · be51bfe9
      Simon McVittie authored
      If we don't trap EEXIST and its Windows equivalent, we are unable to
      detect the situation where we create an ostensibly unique
      subdirectory in a shared /tmp, but an attacker has already created it.
      This affects dbus-nonce (the nonce-tcp transport) and the activation
      reload test.
      
      Add a new _dbus_ensure_directory() for the one case where we want it to
      succeed even on EEXIST: the DBUS_COOKIE_SHA1 keyring, which we know
      we are creating in our own trusted "official" $HOME. In the new
      transient service support on Bug #99825, ensure_owned_directory()
      would need the same treatment.
      
      We are not treating this as a serious security problem, because the
      nonce-tcp transport is rarely enabled on Unix and there are multiple
      mitigations.
      
      The nonce-tcp transport creates a new unique file with O_EXCL and 0600
      (private to user) permissions, then overwrites the requested filename
      via atomic-overwrite, so the worst that could happen there is that an
      attacker could place a symbolic link matching the name of a directory
      we are going to create, causing a dbus-daemon configured for nonce-tcp
      to traverse the symlink and atomically overwrite a file named "nonce"
      in a directory of the attacker's choice, with new random contents that
      are not known to the attacker. This seems unlikely to be exploitable
      for anything worse than denial of service in practice. In mainline
      Linux since 3.6, this attack is also defeated by the
      fs.protected_symlinks sysctl, which many distributions enable by default.
      
      The activation reload test suffers from a classic symlink attack
      due to time-of-check/time-of-use errors in its implementation, but as
      part of the developer-only "embedded tests" that are only intended
      to be run on a trusted machine, it is not treated as security-sensitive.
      That code path will be fixed in a subsequent commit.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99828Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      be51bfe9
  3. 12 Aug, 2016 1 commit
  4. 12 Feb, 2016 1 commit
  5. 11 Feb, 2016 1 commit
  6. 06 Aug, 2015 1 commit
  7. 14 May, 2015 2 commits
  8. 12 May, 2015 5 commits
  9. 24 Mar, 2015 1 commit
  10. 11 Mar, 2015 4 commits
  11. 04 Mar, 2015 2 commits
  12. 24 Feb, 2015 2 commits
  13. 18 Feb, 2015 1 commit
  14. 04 Feb, 2015 2 commits
  15. 06 Nov, 2014 1 commit
  16. 29 Oct, 2014 2 commits
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Consistently save and restore errno · c7fdbe77
      Simon McVittie authored
      Some functions in dbus-transport-socket.c make a (wrapped)
      socket syscall, then call other APIs, then test the result and
      errno of the socket syscall.
      
      This would break horribly if those "other APIs" overwrote errno with
      their own value (... and this is part of why errno is an awful API).
      
      Notably, if running under DBUS_VERBOSE, _dbus_verbose() is basically
      fprintf(), which sets errno; and our Unix fd-passing support
      makes calls of the form _dbus_verbose ("Read/wrote %i unix fds\n", n)
      between the syscall and the result processing.
      
      Maybe one day we'll convert all of dbus' syscall wrappers to either
      raise a DBusError, or use the "negative errno" convention that systemd
      borrowed from the Linux kernel, and in particular, we would need to
      do that if we ever ported it to a platform where socket error reporting
      was not basically errno. However, in practice everyone uses something
      derived from BSD sockets, so "this sets errno, you know what errno is"
      is a good enough internal API if we make sure to use it correctly.
      
      Nothing calls _dbus_get_is_errno_nonzero(), so I just removed it instead
      of converting it to the new calling convention.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83625
      c7fdbe77
  17. 15 Sep, 2014 3 commits
  18. 11 Jun, 2014 1 commit
  19. 28 Apr, 2014 2 commits
    • Chengwei Yang's avatar
      Set argv[0] to dbus-launch to avoid misleading info from /proc · 3e5b148d
      Chengwei Yang authored
      At previous, argv[0] is the full-qualified path of program, however, if
      start dbus-launch failed, it will fall back to find one from $PATH,
      while keep the argv[0] as the full-qualified path. So we'll get
      misleading info from /proc or ps(1) about dbus-launch process.
      
      One simple solution is just hard-code argv[0] to dbus-launch.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69716
      Reviewed-by: Simon McVittie
      3e5b148d
    • Simon McVittie's avatar
      Try to read /etc/machine-id before inventing a new /var/lib/dbus/machine-id · c0304107
      Simon McVittie authored
      It's least confusing if the two files have the same contents. systemd
      already knows how to pick up our /var/lib/dbus/machine-id if it exists
      and /etc/machine-id doesn't, but the converse is not currently true.
      We should make it true, so that it doesn't matter what order
      systemd-machine-id-setup and "dbus-uuidgen --ensure" were
      invoked in.
      
      In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
      will *usually* - but not always! - run first, and the two files will
      match. However, if you install systemd without dbus, and then install
      dbus later, there will be a mismatch. With this change, it doesn't
      matter which one is installed first: whichever one happens to come
      first, it will generate the machine ID, and then the other one will
      copy it.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
      Reviewed-by: Lennart Poettering
      c0304107
  20. 03 Mar, 2014 1 commit
  21. 19 Feb, 2014 2 commits
  22. 06 Jan, 2014 3 commits