1. 30 Sep, 2016 1 commit
    • 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>
      92bd5ef2
  2. 11 Aug, 2016 2 commits
  3. 14 May, 2015 1 commit
  4. 29 Oct, 2014 1 commit
    • 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
  5. 30 Jun, 2014 1 commit
  6. 23 Aug, 2013 1 commit
  7. 17 Jun, 2013 1 commit
  8. 13 May, 2013 1 commit
  9. 28 Sep, 2012 6 commits
    • Colin Walters's avatar
      Revert "hardening: Use __secure_getenv if available" · 19fa7c54
      Colin Walters authored
      It breaks gnome-keyring-daemon at least in some
      configurations; see
      https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24
      
      This reverts commit 1a556443.
      19fa7c54
    • Colin Walters's avatar
      Revert "hardening: Use __secure_getenv if available" · dcee0dd7
      Colin Walters authored
      It breaks gnome-keyring-daemon at least in some
      configurations; see
      https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24
      
      This reverts commit 1a556443.
      dcee0dd7
    • Colin Walters's avatar
      hardening: Use __secure_getenv if available · 1a556443
      Colin Walters authored
      This helps us in the case where we were executed via filesystem
      capabilities or a SELinux domain transition, not necessarily a plain
      old setuid binary.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=52202
      1a556443
    • Colin Walters's avatar
      CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid · a52319bc
      Colin Walters authored
      This matches a corresponding change in GLib.  See
      glib/gutils.c:g_check_setuid().
      
      Some programs attempt to use libdbus when setuid; notably the X.org
      server is shipped in such a configuration. libdbus never had an
      explicit policy about its use in setuid programs.
      
      I'm not sure whether we should advertise such support.  However, given
      that there are real-world programs that do this currently, we can make
      them safer with not too much effort.
      
      Better to fix a problem caused by an interaction between two
      components in *both* places if possible.
      
      How to determine whether or not we're running in a privilege-escalated
      path is operating system specific.  Note that GTK+'s code to check
      euid versus uid worked historically on Unix, more modern systems have
      filesystem capabilities and SELinux domain transitions, neither of
      which are captured by the uid comparison.
      
      On Linux/glibc, the way this works is that the kernel sets an
      AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
      startup.  If found, then glibc sets a public-but-undocumented
      __libc_enable_secure variable which we can use.  Unfortunately, while
      it *previously* worked to check this variable, a combination of newer
      binutils and RPM break it:
      http://www.openwall.com/lists/owl-dev/2012/08/14/1
      
      So for now on Linux/glibc, we fall back to the historical Unix version
      until we get glibc fixed.
      
      On some BSD variants, there is a issetugid() function.  On other Unix
      variants, we fall back to what GTK+ has been doing.
      Reported-by: default avatarSebastian Krahmer <krahmer@suse.de>
      Signed-off-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      a52319bc
    • Colin Walters's avatar
      hardening: Use __secure_getenv if available · d839f027
      Colin Walters authored
      This helps us in the case where we were executed via filesystem
      capabilities or a SELinux domain transition, not necessarily a plain
      old setuid binary.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=52202
      d839f027
    • Colin Walters's avatar
      CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid · 23fe78ce
      Colin Walters authored
      This matches a corresponding change in GLib.  See
      glib/gutils.c:g_check_setuid().
      
      Some programs attempt to use libdbus when setuid; notably the X.org
      server is shipped in such a configuration. libdbus never had an
      explicit policy about its use in setuid programs.
      
      I'm not sure whether we should advertise such support.  However, given
      that there are real-world programs that do this currently, we can make
      them safer with not too much effort.
      
      Better to fix a problem caused by an interaction between two
      components in *both* places if possible.
      
      How to determine whether or not we're running in a privilege-escalated
      path is operating system specific.  Note that GTK+'s code to check
      euid versus uid worked historically on Unix, more modern systems have
      filesystem capabilities and SELinux domain transitions, neither of
      which are captured by the uid comparison.
      
      On Linux/glibc, the way this works is that the kernel sets an
      AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
      startup.  If found, then glibc sets a public-but-undocumented
      __libc_enable_secure variable which we can use.  Unfortunately, while
      it *previously* worked to check this variable, a combination of newer
      binutils and RPM break it:
      http://www.openwall.com/lists/owl-dev/2012/08/14/1
      
      So for now on Linux/glibc, we fall back to the historical Unix version
      until we get glibc fixed.
      
      On some BSD variants, there is a issetugid() function.  On other Unix
      variants, we fall back to what GTK+ has been doing.
      Reported-by: default avatarSebastian Krahmer <krahmer@suse.de>
      Signed-off-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      23fe78ce
  10. 12 Apr, 2012 2 commits
    • David Zeuthen's avatar
      Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method · 87035143
      David Zeuthen authored
      When libdbus-1 moved to using monotonic time support for the
      DBUS_COOKIE_SHA1 authentication was broken, in particular
      interoperability with non-libdbus-1 implementations such as GDBus.
      
      The problem is that if monotonic clocks are available in the OS,
      _dbus_get_current_time() will not return the number of seconds since
      the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
      specification. If both peers are using libdbus-1 it's not a problem
      since both ends will use the wrong time and thus agree. However, if
      the other end is another implementation and following the spec it will
      not work.
      
      First, we change _dbus_get_current_time() back so it always returns
      time since the Epoch and we then rename it _dbus_get_real_time() to
      make this clear. We then introduce _dbus_get_monotonic_time() and
      carefully make all current users of _dbus_get_current_time() use it,
      if applicable. During this audit, one of the callers,
      _dbus_generate_uuid(), was currently using monotonic time but it was
      decided to make it use real time instead.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
      87035143
    • David Zeuthen's avatar
      Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method · 8734e4a1
      David Zeuthen authored
      When libdbus-1 moved to using monotonic time support for the
      DBUS_COOKIE_SHA1 authentication was broken, in particular
      interoperability with non-libdbus-1 implementations such as GDBus.
      
      The problem is that if monotonic clocks are available in the OS,
      _dbus_get_current_time() will not return the number of seconds since
      the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
      specification. If both peers are using libdbus-1 it's not a problem
      since both ends will use the wrong time and thus agree. However, if
      the other end is another implementation and following the spec it will
      not work.
      
      First, we change _dbus_get_current_time() back so it always returns
      time since the Epoch and we then rename it _dbus_get_real_time() to
      make this clear. We then introduce _dbus_get_monotonic_time() and
      carefully make all current users of _dbus_get_current_time() use it,
      if applicable. During this audit, one of the callers,
      _dbus_generate_uuid(), was currently using monotonic time but it was
      decided to make it use real time instead.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
      8734e4a1
  11. 27 Mar, 2012 1 commit
  12. 13 Feb, 2012 1 commit
  13. 08 Feb, 2012 1 commit
  14. 29 Jul, 2011 1 commit
  15. 25 Jul, 2011 1 commit
  16. 17 Jun, 2010 1 commit
  17. 14 Jun, 2010 1 commit
    • Ralf Habacker's avatar
      Bug 28460 - Refactored dbus configuration access. · 6f9077ee
      Ralf Habacker authored
      Libdbus uses several config variables. On unix these settings are read from
      environment variables by using _dbus_getenv.
      
      On other platforms like wince there are no environment variables available and
      _dbus_getenv needs an emulation for those plattforms (see
      dbus/dbus-sysdeps-wince-glue.c)
      
      To cleanup this emulation the appended patch adds a config api by adding
      _dbus_config_... functions.
      
      Also having all client config related functions listed in one header file
      provides a good overview about which config attributes  are available.
      
      The default implementation retrieves the config values from environment
      variables. For other os this could be easily extended or replaced by.
      6f9077ee
  18. 13 Apr, 2010 2 commits
  19. 22 Mar, 2010 1 commit
  20. 19 Mar, 2010 1 commit
  21. 06 Feb, 2010 1 commit
  22. 18 Dec, 2009 2 commits
  23. 01 Dec, 2009 1 commit
  24. 30 Nov, 2009 1 commit
  25. 29 Nov, 2009 1 commit
  26. 14 Jul, 2009 2 commits
  27. 13 Jul, 2009 1 commit
    • Colin Walters's avatar
      Bug 896 - Avoid race conditions reading message from exited process · 0e36cdd5
      Colin Walters authored
      Patch based on extensive work from Michael Meeks <michael.meeks@novell.com>,
      thanks to Dafydd Harries <dafydd.harries@collabora.co.uk>,
      Kimmo Hämäläinen <kimmo.hamalainen@nokia.com> and others.
      
      The basic idea with this bug is that we effectively ignore errors
      on write.  Only when we're done reading from a connection do we
      close down a connection.  This avoids a race condition where
      if a process (such as dbus-send) exited while we still had
      data to read in the buffer, we'd miss that data.
      0e36cdd5
  28. 10 Jul, 2009 1 commit
  29. 06 Jan, 2009 1 commit
  30. 20 Dec, 2008 1 commit