1. 19 Oct, 2020 2 commits
  2. 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 !181
      2285db23
    • 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
      signal-safety(7).
      3fab06d6
  3. 24 Sep, 2020 1 commit
  4. 23 Sep, 2020 4 commits
  5. 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: #310
      2148a5a8
  6. 21 Sep, 2020 1 commit
  7. 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
      https://gitlab.gnome.org/GNOME/glib/-/issues/2164 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>
      3f8b2ce5
  8. 19 Aug, 2020 1 commit
  9. 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
      successfully).
      
      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>
      f0e526bc
  10. 02 Jul, 2020 2 commits
  11. 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 !166
      e75c67a2
    • 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 we want to see when doing access control.
      
      An equivalent situation can occur with groups, in the rare case where
      a numeric group ID has two names (although I have not heard of this
      being done in practice).
      
      Solve this by reference-counting the data structure. There are up to
      three references in practice: one held temporarily while the lookup
      function is populating and storing it, one held by the hash table that
      is indexed by uid, and one held by the hash table that is indexed by
      name.
      
      Closes: #305Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      2b7948ef
  12. 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>
      6ee66ff7
  13. 15 Jun, 2020 1 commit
  14. 12 Jun, 2020 1 commit
  15. 10 Jun, 2020 11 commits
  16. 02 Jun, 2020 4 commits
  17. 01 Jun, 2020 1 commit
  18. 29 May, 2020 3 commits