1. 28 Sep, 2020 2 commits
    • Simon McVittie's avatar
      Merge branch 'glibc' into 'master' · 2285db23
      Simon McVittie authored
      disable fork-malloc-exec for non-glibc-systems
      See merge request dbus/dbus!181
    • Jean-Louis Fuchs's avatar
      disable fork-malloc-exec for non-glibc-systems · 3fab06d6
      Jean-Louis Fuchs authored
      Calling malloc() after fork is undefined behaviour if the process is
      multi-threaded. locks held by a thread on fork() will never be released.
      malloc() is usally protected by a lock and can therefore deadlock. glibc
      is known not to deadlock in this case.
      This commit does not rule out other problems on glibc-systems, but fixes an
      issue on musl-libc-systems. Only restricting to async-signal safe functions
      between fork() and exec() prevents undefined behaviour for sure. See
  2. 24 Sep, 2020 1 commit
  3. 23 Sep, 2020 4 commits
  4. 22 Sep, 2020 1 commit
    • Ralf Habacker's avatar
      cmake: install dbus-daemon-launch-helper on Unix · 2148a5a8
      Ralf Habacker authored
      Previously it was built on Unix platforms, but not installed. This
      would prevent traditional activation on the system bus (on Linux
      without systemd or non-Linux, or for services without SystemdService),
      which requires the activation helper.
      Because the executable is an internal implementation detail of how
      traditional activation is implemented on Unix, it is not exported to
      the generated cmake support files.
      Resolves: dbus#310
  5. 21 Sep, 2020 1 commit
  6. 07 Sep, 2020 1 commit
    • Simon McVittie's avatar
      spec: Update recommendations for DBUS_COOKIE_SHA1 timeouts · 3f8b2ce5
      Simon McVittie authored
      This had two issues that could damage interoperability.
      First, the spec wording suggested that any cookie that had not been
      deleted was suitable for use in authentication. However, this introduces
      a race condition, which is called out in comments in both the reference
      implementation and GDBus: the newest cookie might be less old than the
      arbitrary lifetime when authentication *begins*, but older than the
      lifetime at the time authentication *ends*. As a result, we need a grace
      period during which an old cookie will still be accepted, but a newer
      cookie exists and will be used for new authentication operations.
      Second, the spec wording implied that the arbitrary timeouts were
      completely up to the implementor. However, GLib bug
       indicates that they
      need to be reasonably compatible: in particular, GDBus servers
      historically didn't allocate new cookies until 10 minutes had passed,
      but libdbus clients would decline to use a cookie older than 5 minutes,
      causing authentication to fail if the gdbus-server test-case (in which
      GDBus and libdbus clients connect to a GDBus server) happened to take
      longer than 5 minutes to run.
      While I'm here, also be consistent about calling the secrets "cookies"
      (consistent with the name of the mechanism) rather than "keys" (which
      is what they are called in libdbus' dbus-keyring.c).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  7. 19 Aug, 2020 1 commit
  8. 14 Aug, 2020 1 commit
    • Simon McVittie's avatar
      tests: On Unix, include <netinet/in.h> for IPPROTO_TCP · f0e526bc
      Simon McVittie authored
      Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
      are enabled (which suggests that no FreeBSD user has run those tests
      We already include <netinet/in.h> in other places with no conditions
      or checks other than "is Unix", so apparently it's portable enough that
      specifically testing for its presence is not necessary. POSIX requires it
      to exist.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  9. 02 Jul, 2020 2 commits
  10. 01 Jul, 2020 2 commits
    • Simon McVittie's avatar
      Merge branch 'issue305' into 'master' · e75c67a2
      Simon McVittie authored
      userdb: Reference-count DBusUserInfo, DBusGroupInfo
      Closes #305
      See merge request dbus/dbus!166
    • Simon McVittie's avatar
      userdb: Reference-count DBusUserInfo, DBusGroupInfo · 2b7948ef
      Simon McVittie authored
      Previously, the hash table indexed by uid (or gid) took ownership of the
      single reference to the heap-allocated struct, and the hash table
      indexed by username (or group name) had a borrowed pointer to the same
      struct that exists in the other hash table.
      However, this can break down if you have two or more distinct usernames
      that share a numeric identifier. This is generally a bad idea, because
      the user-space model in such situations does not match the kernel-space
      reality, and in particular there is no effective kernel-level security
      boundary between such users, but it is sometimes done anyway.
      In this case, when the second username is looked up in the userdb, it
      overwrites (replaces) the entry in the hash table that is indexed by
      uid, freeing the DBusUserInfo. This results in both the key and the
      value in the hash table that is indexed by username becoming dangling
      pointers (use-after-free), leading to undefined behaviour, which is
      certainly not what ...
  11. 30 Jun, 2020 1 commit
    • Simon McVittie's avatar
      userdb: Make lookups return a const pointer · 6ee66ff7
      Simon McVittie authored
      This makes it more obvious that the returned pointer points to a
      struct owned by the userdb, which must not be freed or have its
      contents modified, and is only valid to dereference until the next
      modification to the userdb's underlying hash tables (which in practice
      means until the lock is released, because after that we have no
      guarantees about what might be going on in another thread).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  12. 15 Jun, 2020 1 commit
  13. 12 Jun, 2020 1 commit
  14. 10 Jun, 2020 11 commits
  15. 02 Jun, 2020 4 commits
  16. 01 Jun, 2020 1 commit
  17. 29 May, 2020 3 commits
  18. 28 May, 2020 1 commit
  19. 16 May, 2020 1 commit
    • Ralf Habacker's avatar
      cmake: Let Wine display the correct file name and line numbers for backtraces · 9738a48a
      Ralf Habacker authored
      Wine currently only supports the symbol formats STABS and DWARF 2,
      but not the other versions, with STABS providing the most information
      and being the first choice.
      Since we already use the cmake variable DBUS_USE_WINE for running tests
      under Wine, we also use it to activate the special symbol format.
      Closes dbus/dbus/#133