1. 11 Feb, 2015 2 commits
  2. 04 Feb, 2015 1 commit
  3. 30 Jan, 2015 2 commits
  4. 23 Dec, 2014 1 commit
  5. 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
  6. 15 Sep, 2014 1 commit
    • Simon McVittie's avatar
      Split _dbus_fd_set_close_on_exec into Unix and Windows versions · 3765075c
      Simon McVittie authored
      On Unix, the thing that can be made close-on-exec is a file descriptor,
      which is an int.
      
      On Windows, the thing that can be made close-on-exec is a HANDLE,
      which is pointer-sized (but not necessarily a pointer!). In practice,
      on Windows we only called _dbus_fd_set_close_on_exec() on socket
      pseudo-file-descriptors (SOCKET, which is an unsigned int);
      every SOCKET can validly be cast to HANDLE, but not every HANDLE
      is a SOCKET.
      
      Before this commit we used an intptr_t as a sort of fake
      union { int; HANDLE; }, which just obscures what's going on.
      
      In practice, everything that called _dbus_fd_set_close_on_exec()
      is really platform-specific anyway, so let's just have two separate
      functions and call this solved.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39610
      3765075c
  7. 07 Jan, 2014 1 commit
  8. 27 Nov, 2013 1 commit
    • Matt Fischer's avatar
      Fix for MinGW build · eca9a5a2
      Matt Fischer authored
      dbus-sysdeps-win.c makes use of a constant called
      PROCESS_QUERY_LIMITED_INFORMATION, which was added after Windows
      XP.  There is code present to make sure the constant is not used
      when running on an XP system, but the constant is still required
      at build time.  Unfortunately, the Windows headers provided by
      MinGW are old enough that they do not contain this constant, so
      building with MinGW fails.
      
      This patch adds a definition for the constant if one is not already
      present.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71366Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      [altered comment to specify MinGW32 < 4, since mingw-w64
      and MinGW 4.0+ do have this constant -smcv]
      eca9a5a2
  9. 16 Sep, 2013 1 commit
    • Simon McVittie's avatar
      dbus-sysdeps-win: don't include wspiapi.h · 3b9c2817
      Simon McVittie authored
      This block provoked a warning on mingw-w64 because we were redefining
      _inline. According to Ralf's research, it was introduced in 452ff68a:
      Windows 2000 doesn't have getaddrinfo and related functions in
      ws2tcpip.h, but does have a shim implementation in wspiapi.h.
      
      At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
      why there was a __GNUC__ code path here. The "#define _inline" on that
      code path looks likely to be some sort of workaround for a faulty version
      of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
      __GNUC__ code path and get the redefinition.
      
      dbus no longer supports Windows 2000, so we no longer need wspiapi.h
      at all, and can rely on XP or later. (Ralf's policy is to only support
      versions of Windows that are still supported by Microsoft, and Windows 2000
      reached the end of its life-cycle in 2010.)
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
      Reviewed-by: Ralf Habacker
      3b9c2817
  10. 30 Aug, 2013 3 commits
  11. 29 Aug, 2013 1 commit
  12. 28 Aug, 2013 1 commit
  13. 22 Aug, 2013 1 commit
  14. 09 Aug, 2013 7 commits
  15. 07 Aug, 2013 2 commits
  16. 28 Jun, 2013 1 commit
  17. 25 Jun, 2013 1 commit
  18. 12 Jun, 2013 1 commit
  19. 09 May, 2013 1 commit
  20. 05 Apr, 2013 1 commit
  21. 08 Mar, 2013 3 commits
  22. 09 Nov, 2012 1 commit
  23. 28 Sep, 2012 2 commits
    • 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
      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
  24. 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
  25. 04 Jan, 2012 1 commit
    • Simon McVittie's avatar
      Revert all changes since a36d4918 · 5df8c3db
      Simon McVittie authored
      Someone seems to have merged part of master into 1.4. Again. Let's go
      back to the "last known good" point (the branch-point of some 1.4
      branches I had locally), then we can cherry-pick the changes that
      should have gone in.
      5df8c3db