1. 19 Aug, 2020 1 commit
  2. 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
  3. 02 Jul, 2020 2 commits
  4. 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
      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: dbus#305
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      2b7948ef
  5. 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
  6. 15 Jun, 2020 1 commit
  7. 12 Jun, 2020 1 commit
  8. 10 Jun, 2020 11 commits
  9. 02 Jun, 2020 4 commits
  10. 01 Jun, 2020 1 commit
  11. 29 May, 2020 3 commits
  12. 28 May, 2020 1 commit
  13. 16 May, 2020 2 commits
  14. 04 May, 2020 1 commit
  15. 30 Apr, 2020 1 commit
  16. 29 Apr, 2020 7 commits