1. 13 Oct, 2016 1 commit
    • 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>
      Reviewed-by: default avatarThomas Zimmermann <tdz@users.sourceforge.net>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
      8db5ca90
  2. 30 Sep, 2016 1 commit
  3. 14 May, 2015 1 commit
  4. 12 May, 2015 2 commits
  5. 18 Feb, 2015 1 commit
  6. 15 Sep, 2014 2 commits
  7. 13 Sep, 2013 1 commit
  8. 23 Aug, 2013 3 commits
  9. 22 Aug, 2013 3 commits
  10. 28 Jun, 2013 1 commit
  11. 25 Jun, 2013 2 commits
  12. 20 Jun, 2013 2 commits
  13. 17 Jun, 2013 2 commits
  14. 05 Apr, 2013 1 commit
  15. 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
  16. 12 Mar, 2012 1 commit
    • Lennart Poettering's avatar
      transport: add new unixexec transport on Unix · f67f4597
      Lennart Poettering authored
      The "unixexec:" transport will create a local AF_UNIX socket with
      socketpair(), then fork and execute a binary on one side with STDIN and
      STDOUT connected to it and then use the other side.
      
      This is useful to implement D-Bus tunneling schemes, for example to get
      a D-Bus connection to the system bus on a different host, similar how
      udisks is already doing it. (udisks uses SSH TCP tunneling for this,
      which is a bit ugly and less secure than this solution).
      
      Suggested use is with connection strings like the following:
      
        unixexec:path=ssh,argv1=foobar,argv2=system-bus-bridge
      
      or:
      
        unixexec:path=pkexec,argv1=system-bus-bridge
      
      or even:
      
        unixexec:path=sudo,argv1=system-bus-bridge
      
      The first line would execute the binary 'system-bus-bridge' on host
      'foobar' and then pass D-Bus traffic to it. This (hypothetical) bridge
      binary would then forward the information to the local system bus.
      
      The second and third line use this scheme locally to acquire a
      privileged connection through pkexec resp. sudo: instead of connecting
      directly to the bus, they use the same bridge binary which will forward
      all information to the system bus.
      
      The arguments of the protocol are 'path' for the first execlp()
      argument, and argv0, argv1, and so on for the following arguments. argv0
      can be left out in which case path will be used.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      f67f4597
  17. 21 Feb, 2012 1 commit
    • Simon McVittie's avatar
      Distinguish between two flavours of mutex · 8a58250a
      Simon McVittie authored
      dbus-threads.h warns that recursive pthreads mutexes are not compatible
      with our expectations for condition variables. However, the only two
      condition variables we actually use only have their corresponding
      mutexes locked briefly (and we don't call out to user code from there),
      so the mutexes don't need to be recursive anyway. That's just as well,
      because it turns out our implementation of recursive mutexes on
      pthreads is broken!
      
      The goal here is to be able to distinguish between "cmutexes" (mutexes
      compatible with a condition variable) and "rmutexes" (mutexes which
      are recursive if possible, to avoid deadlocking if we hold them while
      calling user code).
      
      This is complicated by the fact that callers are not guaranteed to have
      provided us with both versions of mutexes, so we might have to implement
      one by using the other (in particular, DBusRMutex *aims to be*
      recursive, it is not *guaranteed to be* recursive).
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Thiago Macieira's avatarThiago Macieira <thiago@kde.org>
      8a58250a
  18. 13 Feb, 2012 2 commits
  19. 10 Feb, 2012 1 commit
  20. 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
  21. 19 Sep, 2011 1 commit
  22. 29 Jul, 2011 1 commit
  23. 28 Jul, 2011 7 commits