1. 14 Nov, 2019 1 commit
  2. 11 Nov, 2019 1 commit
  3. 04 Nov, 2019 4 commits
  4. 31 Oct, 2019 1 commit
    • Mattias Bengtsson's avatar
      gdbus-codegen: Safer header guards · 4aaeac5b
      Mattias Bengtsson authored
      Whitelist a safe set of characters for use in header guards instead of
      maintaining a (growing) blacklist.
      The whitelist is intentionally short since reading up on all
      peculiarities of the C and C++ standard for identifiers is not my idea
      of fun. :)
      Fixes #1379
  5. 30 Oct, 2019 4 commits
  6. 29 Oct, 2019 4 commits
  7. 28 Oct, 2019 11 commits
    • Philip Withnall's avatar
      gdbusserver: Keep a strong reference to the server in callbacks · 0c07e672
      Philip Withnall authored
      The `on_run()` function could be executed in any worker thread from the
      `GThreadedSocketListener`, but didn’t previously hold a strong reference
      to the `GDBusServer`, which meant the server could be finalised in
      another thread while `on_run()` was still running.
      This was not ideal.
      Hold a strong reference to the `GDBusServer` while the socket listener
      is listening, i.e. between every paired call to `g_dbus_server_start()`
      and `g_dbus_server_stop()`.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Fixes: #1318
    • Philip Withnall's avatar
      gdbusserver: Delete socket and nonce file when stopping server · 8e32b8e8
      Philip Withnall authored
      Rather than when finalising it. They should be automatically recreated
      if the server is re-started.
      This is important for ensuring that all externally visible behaviour of
      the `GDBusServer` is synchronised with calls to
      g_dbus_server_{start,stop}(). Finalisation of the server object could
      happen an arbitrarily long time after g_dbus_server_stop() is called.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1318
    • Philip Withnall's avatar
      tests: Isolate directories in gdbus-peer test · 6fb38c3f
      Philip Withnall authored
      So that the tests all end up using separate `.dbus-keyring` directories,
      and hence not racing to create and acquire lock files, use
      `G_TEST_OPTION_ISOLATE_DIRS` to ensure they all run in separate
      disposable directories.
      This has the added benefit of meaning they don’t touch the developer’s
      actual `$HOME` directory.
      This reduces the false-failure rate of `gdbus-peer` by a factor of 9 for
      me on my local machine.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Fixes: #1912
    • Philip Withnall's avatar
      tests: Move main loop and test GUID into test functions in gdbus-peer · 833579d9
      Philip Withnall authored
      There’s actually no need for them to be global or reused between unit
      tests, so move them inside the test functions.
      This is one step towards eliminating shared state between the unit
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1912
    • Philip Withnall's avatar
      gdbusauthmechanismsha1: Create .dbus-keyrings directory recursively · 9df8d76c
      Philip Withnall authored
      If the directory is overridden, for example when running tests, the
      parent directory of `.dbus-keyrings` (i.e. the fake `$HOME` directory)
      might not exist. Create it automatically.
      This should realistically not have an effect on non-test code.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1912
    • Philip Withnall's avatar
      gdbusauthmechanismsha1: Remove unnecessary g_warning() calls · ef3eec8a
      Philip Withnall authored
      These can be hit in the tests (if multiple tests run in parallel are
      racing for `~/.dbus-keyrings/org_gtk_gdbus_general.lock` for a prolonged
      period) and will cause spurious test failures due to the use of
      Instead, allow the error messages to be inspected programmatically.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1912
    • Simon McVittie's avatar
      Add a test for GDBusServer authentication · 9f962ebe
      Simon McVittie authored
      In particular, if libbdus is available, we test interoperability with
      a libdbus client: see #1831. Because that issue describes a
      race condition, we do each test repeatedly to try to hit the failing
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      GDBus: prefer getsockopt()-style credentials-passing APIs · ee502dbb
      Simon McVittie authored
      Conceptually, a D-Bus server is really trying to determine the credentials
      of (the process that initiated) a connection, not the credentials that
      the process had when it sent a particular message. Ideally, it does
      this with a getsockopt()-style API that queries the credentials of the
      connection's initiator without requiring any particular cooperation from
      that process, avoiding a class of possible failures.
      The leading '\0' in the D-Bus protocol is primarily a workaround
      for platforms where the message-based credentials-passing API is
      strictly better than the getsockopt()-style API (for example, on
      FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not),
      or where the getsockopt()-style API does not exist at all. As a result
      libdbus, the reference implementation of D-Bus, does not implement
      Linux SCM_CREDENTIALS at all - it has no reason to do so, because the
      SO_PEERCRED socket option is equally informative.
      This change makes GDBusServer on Linux more closely match the behaviour
      of libdbus.
      In particular, #1831 indicates that when a libdbus client
      connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS
      message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is
      most likely a race condition in the early steps to connect:
              client           server
          send '\0' <- race -> set SO_PASSCRED = 1
                               receive '\0'
      If the server wins the race:
              client           server
                               set SO_PASSCRED = 1
          send '\0'
                               receive '\0'
      then everything is fine. However, if the client wins the race:
              client           server
          send '\0'
                               set SO_PASSCRED = 1
                               receive '\0'
      then the kernel does not record credentials for the message containing
      '\0' (because SO_PASSCRED was 0 at the time). However, by the time the
      server receives the message, the kernel knows that credentials are
      desired. I would have expected the kernel to omit the credentials header
      in this case, but it seems that instead, it synthesizes a credentials
      structure with a dummy process ID 0, a dummy uid derived from
      /proc/sys/kernel/overflowuid and a dummy gid derived from
      In an unconfigured GDBusServer, hitting this race condition results in
      falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually
      succeeds in authenticating the peer's uid. However, we encourage AF_UNIX
      servers on Unix platforms to allow only EXTERNAL authentication as a
      security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series
      of assumptions including a cryptographically strong PRNG and a shared
      home directory with no write access by others, which are not necessarily
      true for all operating systems and users. EXTERNAL authentication will
      fail if the server cannot determine the client's credentials.
      In particular, this caused a regression when CVE-2019-14822 was fixed
      in ibus, which appears to be resolved by this commit. Qt clients
      (which use libdbus) intermittently fail to connect to an ibus server
      (which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1
      authentication or non-matching uids.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Closes: #1831
    • Simon McVittie's avatar
      credentials: Invalid Linux struct ucred means "no information" · 1485a97d
      Simon McVittie authored
      On Linux, if getsockopt SO_PEERCRED is used on a TCP socket, one
      might expect it to fail with an appropriate error like ENOTSUP or
      EPROTONOSUPPORT. However, it appears that in fact it succeeds, but
      yields a credentials structure with pid 0, uid -1 and gid -1. These
      are not real process, user and group IDs that can be allocated to a
      real process (pid 0 needs to be reserved to give kill(0) its documented
      special semantics, and similarly uid and gid -1 need to be reserved for
      setresuid() and setresgid()) so it is not meaningful to signal them to
      high-level API users.
      An API user with Linux-specific knowledge can still inspect these fields
      via g_credentials_get_native() if desired.
      Similarly, if SO_PASSCRED is used to receive a SCM_CREDENTIALS message
      on a receiving Unix socket, but the sending socket had not enabled
      SO_PASSCRED at the time that the message was sent, it is possible
      for it to succeed but yield a credentials structure with pid 0, uid
      /proc/sys/kernel/overflowuid and gid /proc/sys/kernel/overflowgid. Even
      if we were to read those pseudo-files, we cannot distinguish between
      the overflow IDs and a real process that legitimately has the same IDs
      (typically they are set to 'nobody' and 'nogroup', which can be used
      by a real process), so we detect this situation by noticing that
      pid == 0, and to save syscalls we do not read the overflow IDs from
      /proc at all.
      This results in a small API change: g_credentials_is_same_user() now
      returns FALSE if we compare two credentials structures that are both
      invalid. This seems like reasonable, conservative behaviour: if we cannot
      prove that they are the same user, we should assume they are not.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
    • Philip Withnall's avatar
      tests: Use objcopy from the cross-compilation file, if configured · 2d2e96dc
      Philip Withnall authored
      Otherwise we’ll end up using the host’s `objcopy`, which will output
      object files in the wrong format.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Fixes: #1916
  8. 26 Oct, 2019 1 commit
  9. 25 Oct, 2019 1 commit
  10. 18 Oct, 2019 2 commits
  11. 11 Oct, 2019 3 commits
  12. 10 Oct, 2019 3 commits
  13. 08 Oct, 2019 3 commits
  14. 07 Oct, 2019 1 commit
    • Ondrej Holy's avatar
      gio: Always include mounts in the results · b3bf1e26
      Ondrej Holy authored
      Mounts are currently completed only if the prefix looks like scheme,
      however, this doesn't work well if the mounts have also path component.
      Let's always include them to fix this issue. The mounts are cached by the
      volume monitors, so it should not significantly affect the performance.