1. 26 Mar, 2020 2 commits
  2. 11 Mar, 2020 1 commit
  3. 12 Dec, 2019 1 commit
    • Simon McVittie's avatar
      _dbus_modify_sigpipe: be thread-safe · bf20f738
      Simon McVittie authored and Ralf Habacker's avatar Ralf Habacker committed
      This needs new atomic primitives: we don't have "set to a value",
      and in fact that's a bit annoying to implement in terms of gcc
      intrinsics. "Set to 0" and "set to nonzero" are easy, though.
  4. 23 Jan, 2019 1 commit
  5. 20 Nov, 2018 2 commits
  6. 19 Nov, 2018 1 commit
    • Simon McVittie's avatar
      build: Drop support for non-POSIX getpwnam_r(), getgrnam_r() · e57120cb
      Simon McVittie authored
      Solaris 2.3 and 2.4 took their getpwnam_r() signature from draft 6
      of the POSIX threads standard. Since Solaris 2.5 (1995), defining
      _POSIX_PTHREAD_SEMANTICS opts-in to the non-draft version of
      getpwnam_r(), and since Solaris 11.4 (2018), the non-draft version is
      the default.
      We already use AC_USE_SYSTEM_EXTENSIONS, which defines
      _POSIX_PTHREAD_SEMANTICS, among other useful macros.
      Thanks to Alan Coopersmith for assistance with Solaris history.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  7. 18 Oct, 2018 1 commit
  8. 02 Aug, 2018 1 commit
    • Simon McVittie's avatar
      sysdeps: Reassure gcc 8 that we are not overflowing struct sockaddr_un · f4296313
      Simon McVittie authored
      Using strncpy (buffer, str, strlen (str)) is a "code smell" that
      might indicate a serious bug (it effectively turns strncpy into
      strcpy), and gcc 8 now warns about it. In fact we avoided the bug
      here, but it wasn't at all obvious.
      We already checked that path_len is less than or equal to
      _DBUS_MAX_SUN_PATH_LENGTH, which is 99, chosen to be strictly less
      than the POSIX minimum sizeof(sun_path) >= 100, so we couldn't
      actually be overflowing the available buffer.
      The new static assertion in this commit matches a comment above the
      definition of _DBUS_MAX_SUN_PATH_LENGTH: we define
      _DBUS_MAX_SUN_PATH_LENGTH to 99, because POSIX says struct
      sockaddr_un's sun_path member is at least 100 bytes (including space
      for a \0 terminator). dbus will now fail to compile on
      platforms that are non-POSIX-compliant in this way, except for Windows.
      We zeroed the struct sockaddr_un before writing into it, so stopping
      one byte short of the end of sun_path ensures that we get \0
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107350
      Reviewed-by: Thiago Macieira's avatarThiago Macieira <thiago@kde.org>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  9. 04 Jun, 2018 1 commit
  10. 19 Mar, 2018 1 commit
  11. 12 Mar, 2018 1 commit
  12. 10 Mar, 2018 2 commits
  13. 09 Mar, 2018 6 commits
  14. 02 Mar, 2018 2 commits
  15. 24 Nov, 2017 1 commit
  16. 15 Nov, 2017 1 commit
  17. 29 Sep, 2017 1 commit
  18. 25 Sep, 2017 1 commit
  19. 15 Aug, 2017 2 commits
  20. 28 Jul, 2017 1 commit
    • Simon McVittie's avatar
      userdb: Respect $HOME for the home directory of our own uid · 3f377c51
      Simon McVittie authored
      This lets cooperating processes with the same value of $HOME
      interoperate for DBUS_COOKIE_SHA1 by reading and writing $HOME, even
      if their $HOME differs from the uid's "official" home directory
      according to getpwuid(). Out of paranoia, we only do this if the uid
      and the euid are equal, since if they were unequal the correct thing
      to do would be ambiguous.
      In particular, Debian autobuilders run as a user whose "official"
      home directory in /etc/passwd is "/nonexistent", as a mechanism to
      detect non-deterministic build processes that rely on the contents of
      the home directory. Until now, this meant we couldn't run dbus'
      build-time tests, because every test that used DBUS_COOKIE_SHA1 would
      fail in this environment.
      In the tests, set HOME as well as DBUS_TEST_HOMEDIR. We keep
      DBUS_TEST_HOMEDIR too, because Windows doesn't use HOME, only HOMEDRIVE
      and HOMEPATH.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101960
      Bug-Debian: https://bugs.debian.org/630152
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  21. 05 Jul, 2017 1 commit
  22. 08 Jun, 2017 2 commits
    • Simon McVittie's avatar
      Make _dbus_get_local_machine_uuid_encoded() properly failable · 6f751caf
      Simon McVittie authored
      This function already raised an error, and all callers handled that
      error as gracefully as they could (because _dbus_generate_uuid() is
      failable, since 2015). Given that, it seems unnecessarily hostile
      to do a _dbus_warn_check_failed() unless we have no better alternative:
      yes, it indicates that dbus has not been installed correctly, but
      during build-time tests it's entirely reasonable that dbus has not
      yet been installed.
      Callers are:
      * DBusConnection, to implement Peer.GetMachineId()
      * The bus driver, to implement Peer.GetMachineId()
      * X11 autolaunching
      * dbus_get_local_machine_id()
      Of those, only the last one is not in a position to return an error
      gracefully, so move the _dbus_warn_check_failed() to there.
      Migrate the text about the D-Bus library being incorrectly set up
      into the error emitted by the Unix implementation, and to make it
      less misleading, include separate error messages for both the
      files we try to read:
      $ bwrap --ro-bind / / --dev /dev --tmpfs /etc --tmpfs /var \
        ./tools/dbus-uuidgen --get
      D-Bus library appears to be incorrectly set up: see the manual
      page for dbus-uuidgen to correct this issue. (Failed to open
      "/var/lib/dbus/machine-id": No such file or directory; Failed to open
      "/etc/machine-id": No such file or directory)
      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=13194
    • Simon McVittie's avatar
      Unix sysdeps: Only copy /etc/machine-id to ${sysconfdir} in "ensure" mode · bde40c89
      Simon McVittie authored
      System integration scripts use dbus-uuidgen --ensure, so they are
      unaffected by this, and in particular the solution to Bug #77941
      is still valid.
      The shared library is typically loaded by unprivileged users, so
      trying to write out the machine-id file is not going to work anyway.
      However, if we *can* write to our ${sysconfdir} - notably during
      `make distcheck` - then it is unexpected that merely reading the
      machine ID has the side-effect of writing to ${sysconfdir},
      and in particular it will make the check for a complete uninstall
      fail. We definitely must not delete the machine ID during
      `make uninstall`.
      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=101257
  23. 07 Apr, 2017 1 commit
  24. 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
      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=99828
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  25. 13 Oct, 2016 3 commits
    • Simon McVittie's avatar
      _dbus_listen_tcp_socket: correct format string · a14fcb70
      Simon McVittie authored
      res is an integer, not a string.
      Bug found by adding more _DBUS_GNUC_PRINTF attributes.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
    • Simon McVittie's avatar
      Linux: use readdir(), not deprecated readdir_r() · e82ec99e
      Simon McVittie authored
      glibc >= 2.24 marks readdir_r() as deprecated. It is meant to be a
      thread-safe version of readdir(), but modern implementations of readdir()
      are thread-safe anyway (when called with a distinct DIR * argument),
      and readdir_r() has some design issues involving PATH_MAX.
      This code path is in Linux-specific code, so we can safely assume a
      high-quality implementation of readdir().
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>
      Reviewed-by: default avatarThomas Zimmermann <tdz@users.sourceforge.net>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
    • Simon McVittie's avatar
      Be more const-correct · 8db5ca90
      Simon McVittie authored
      As a general design principle, strings that we aren't going to modify
      should usually be const. When compiling with -Wwrite-strings, quoted
      string constants are of type "const char *", causing compiler warnings
      when they are assigned to char * variables.
      Unfortunately, we need to add casts in a few places:
      * _dbus_list_append(), _dbus_test_oom_handling() and similar generic
        "user-data" APIs take a void *, not a const void *, so we have
        to cast
      * For historical reasons the execve() family of functions take a
        (char * const *), i.e. a constant pointer to an array of mutable
        strings, so again we have to cast
      * _dbus_spawn_async_with_babysitter similarly takes a char **,
        although we can make it a little more const-correct by making it
        take (char * const *) like execve() does
      This also incorporates a subsequent patch by Thomas Zimmermann to
      put various string constants in static storage, which is a little
      more efficient.
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>
  26. 30 Sep, 2016 2 commits
    • Simon McVittie's avatar
      Remove trailing newlines from _dbus_warn, _dbus_warn_check_failed · f1cd229f
      Simon McVittie authored
      They used to be needed, but are not needed any more, and we were
      never completely consistent about including them in any case.
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>
    • Simon McVittie's avatar
      _dbus_logv: configurably log to syslog and/or stderr · 92bd5ef2
      Simon McVittie authored
      This changes the behaviour of _dbus_logv() if _dbus_init_system_log() was
      not called. Previously, _dbus_logv() would always log to syslog;
      additionally, it would log to stderr, unless the process is dbus-daemon
      and it was started by systemd. Now, it will log to stderr only,
      unless _dbus_init_system_log() was called first.
      This is the desired behaviour because when we hook up
      _dbus_warn_check_failed() to _dbus_logv() in the next commit, we don't
      want typical users of libdbus to start logging their check failures to
      syslog - we only want the dbus-daemon to do that.
      In practice this is not usually a behaviour change, because there was
      only one situation in which we called _dbus_logv() without first calling
      _dbus_init_system_log(), namely an error while parsing configuration
      files. Initialize the system log "just in time" in that situation
      to preserve existing behaviour.
      Signed-off-by: default avatarSimon McVittie <smcv@debian.org>