summaryrefslogtreecommitdiff
path: root/dbus
Commit message (Collapse)AuthorAgeFilesLines
* userdb: Reference-count DBusUserInfo, DBusGroupInfoSimon McVittie2020-07-024-27/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the hash table indexed by uid (or gid) took ownership of the single reference to the heap-allocated struct, and the hash table indexed by username (or group name) had a borrowed pointer to the same struct that exists in the other hash table. However, this can break down if you have two or more distinct usernames that share a numeric identifier. This is generally a bad idea, because the user-space model in such situations does not match the kernel-space reality, and in particular there is no effective kernel-level security boundary between such users, but it is sometimes done anyway. In this case, when the second username is looked up in the userdb, it overwrites (replaces) the entry in the hash table that is indexed by uid, freeing the DBusUserInfo. This results in both the key and the value in the hash table that is indexed by username becoming dangling pointers (use-after-free), leading to undefined behaviour, which is certainly not what we want to see when doing access control. An equivalent situation can occur with groups, in the rare case where a numeric group ID has two names (although I have not heard of this being done in practice). Solve this by reference-counting the data structure. There are up to three references in practice: one held temporarily while the lookup function is populating and storing it, one held by the hash table that is indexed by uid, and one held by the hash table that is indexed by name. Closes: dbus#305 Signed-off-by: Simon McVittie <smcv@collabora.com> (cherry picked from commit 2b7948ef907669e844b52c4fa2268d6e3162a70c)
* userdb: Make lookups return a const pointerSimon McVittie2020-07-023-9/+13
| | | | | | | | | | | | This makes it more obvious that the returned pointer points to a struct owned by the userdb, which must not be freed or have its contents modified, and is only valid to dereference until the next modification to the userdb's underlying hash tables (which in practice means until the lock is released, because after that we have no guarantees about what might be going on in another thread). Signed-off-by: Simon McVittie <smcv@collabora.com> (cherry picked from commit 6ee66ff7bcc91803111d950512f02651e664f74f)
* Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNCAndy Fiddaman2020-07-021-1/+20
| | | | (cherry picked from commit b96ef23e406baa08648339a53b0161fc80de7ce4)
* sysdeps-unix: On MSG_CTRUNC, close the fds we did receiveSimon McVittie2020-06-021-12/+20
| | | | | | | | | | | | | | | | | | | MSG_CTRUNC indicates that we have received fewer fds that we should have done because the buffer was too small, but we were treating it as though it indicated that we received *no* fds. If we received any, we still have to make sure we close them, otherwise they will be leaked. On the system bus, if an attacker can induce us to leak fds in this way, that's a local denial of service via resource exhaustion. [Backport to dbus-1.10: Change signedness of iterator due to commit ab8cb96e "_dbus_read_socket_with_unix_fds: make n_fds unsigned" not having been applied to this branch.] Reported-by: Kevin Backhouse, GitHub Security Lab Fixes: dbus#294 Fixes: CVE-2020-12049 Fixes: GHSL-2020-057
* test: Add basic test coverage for DBUS_COOKIE_SHA1Simon McVittie2019-06-094-3/+159
| | | | | | | | | We don't actually complete successful authentication, because that would require us to generate a cookie and compute the correct SHA1, which is difficult to do in a deterministic authentication script. However, we do assert that dbus#269 (CVE-2019-12749) has been fixed. Signed-off-by: Simon McVittie <smcv@collabora.com>
* auth: Reject DBUS_COOKIE_SHA1 for users other than the server ownerSimon McVittie2019-06-091-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership of a shared home directory by having the server write a secret "cookie" into a .dbus-keyrings subdirectory of the desired identity's home directory with 0700 permissions, and having the client prove that it can read the cookie. This never actually worked for non-malicious clients in the case where server uid != client uid (unless the server and client both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional Unix uid 0) because an unprivileged server would fail to write out the cookie, and an unprivileged client would be unable to read the resulting file owned by the server. Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings is owned by the uid of the server (a side-effect of a check added to harden our use of XDG_RUNTIME_DIR), further ruling out successful use by a non-malicious client with a uid differing from the server's. Joe Vennix of Apple Information Security discovered that the implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link attack: a malicious client with write access to its own home directory could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to read and write in unintended locations. In the worst case this could result in the DBusServer reusing a cookie that is known to the malicious client, and treating that cookie as evidence that a subsequent client connection came from an attacker-chosen uid, allowing authentication bypass. This is mitigated by the fact that by default, the well-known system dbus-daemon (since 2003) and the well-known session dbus-daemon (in stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1 at an early stage, before manipulating cookies. As a result, this vulnerability only applies to: * system or session dbus-daemons with non-standard configuration * third-party dbus-daemon invocations such as at-spi2-core (although in practice at-spi2-core also only accepts EXTERNAL by default) * third-party uses of DBusServer such as the one in Upstart Avoiding symlink attacks in a portable way is difficult, because APIs like openat() and Linux /proc/self/fd are not universally available. However, because DBUS_COOKIE_SHA1 already doesn't work in practice for a non-matching uid, we can solve this vulnerability in an easier way without regressions, by rejecting it early (before looking at ~/.dbus-keyrings) whenever the requested identity doesn't match the identity of the process hosting the DBusServer. Signed-off-by: Simon McVittie <smcv@collabora.com> Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269 Closes: CVE-2019-12749
* Include string.h for strcmp()Thomas Zimmermann2018-12-031-0/+1
| | | | | | | Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net> Reviewed-by: Simon McVittie <smcv@debian.org> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357 (cherry picked from commit ddbc44adb2709f6dc248364f02b8b4207ea5a1af)
* Do not apply __attribute__((__malloc__)) to dbus_realloc()Simon McVittie2018-08-301-1/+0
| | | | | | | | | | | | | | | | | | As noted in GLib commit c879f50f, gcc's interpretation of the malloc attribute has become more strict over time, which could result in miscompilation. The new definition is that in addition to assuming that the returned memory block is newly-allocated, gcc now assumes that it does not contain any valid pointers. This is OK for uninitialized or zero-initialized memory returned by dbus_malloc() or dbus_malloc0(), but not valid for dbus_realloc(), which might be used for a dynamically-sized array of (structures containing) valid pointers. See https://gitlab.gnome.org/GNOME/glib/issues/1465 Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107741
* validate_body_helper: Bounds-check before validating booleansSimon McVittie2018-08-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Running the "embedded tests" through valgrind revealed that before this commit, we would have been willing to read up to 3 bytes off the end of a message if the message is truncated part way through a boolean. Any practical allocator will round up allocations to the next 32-bit (or larger) boundary, so in practice this will not leave the memory buffer (and in particular did not crash during unit testing), but it could read uninitialized contents. On little-endian CPUs, an attacker might be able to use this to learn whether up to 3 bytes of uninitialized memory in the dbus-daemon were all-zero (their crafted message would be relayed) or not (their connection would be disconnected for sending an invalid message). On big-endian CPUs, an attacker might be able to use this to learn whether up to 3 bytes were all-zeroes (relayed to a cooperating peer), 0-2 bytes of all-zeroes followed by 0x01 (relayed to a cooperating peer), or something else (disconnected). This is not believed to be exploitable to leak interesting information. Fixes: 62e46533 "hardcode dbus_bool_t to 32 bits" Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107332 Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Thiago Macieira <thiago@kde.org> Reviewed-by: Philip Withnall <withnall@endlessm.com> (cherry picked from commit e93a775e68daeda5c95984452aee6327e31c17dd)
* sysdeps: Reassure gcc 8 that we are not overflowing struct sockaddr_unSimon McVittie2018-08-021-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 termination. Signed-off-by: Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107350 Reviewed-by: Thiago Macieira <thiago@kde.org> Reviewed-by: Philip Withnall <withnall@endlessm.com> (cherry picked from commit f429631365ba59a1749438af2184cab138a31772)
* Fix -Werror=declaration-after-statement build failure on SolarisAlan Coopersmith2017-08-151-4/+5
| | | | | | | | | | | | dbus-sysdeps-unix.c: In function ‘_dbus_read_credentials_socket’: dbus-sysdeps-unix.c:2061:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] adt_session_data_t *adth = NULL; ^ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102145 Reviewed-by: Philip Withnall <withnall@endlessm.com> Reviewed-by: Simon McVittie <smcv@collabora.com>
* sysdeps: increase listen() backlog of AF_UNIX sockets to SOMAXCONNLennart Poettering2017-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the listen() backlog was set to an arbitrary 30. This means that if dbus-daemon is overloaded only 30 more connections may be queued by the kernel, before connect() fails with EAGAIN. (Note that EAGAIN != EINPROGRESS -- the latter is what is returned if a connection is queued and being processed for asynchronous sockets; EAGAIN in this case is really an error, that cannot be recovered from). Most software simply sets SOMAXCONN as backlog for AF_UNIX sockets, to allow queuing of as many connections as the kernel allows. SOMAXCONN is 128 on Linux, which is not particularly high, but at least higher than 30. This patch changes dbus-daemon to do the same. I noticed this when flooding dbus-daemon with a lot of connections, where it pretty quickly ceased to respond, much earlier than it really should. Note that the backlog has nothing to do with the number of concurrent connections allowed, it simply controls how many queued, but not accept()ed connections there may be on the listening socket. (cherry picked from commit 12bd6e893c91430fdbdf8a27087d4a792b04eef9) Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95264 Bug-Debian: https://bugs.debian.org/872144 Reviewed-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Thiago Macieira <thiago@kde.org>
* dbus_message_iter_open_container: Don't leak signature on failureSimon McVittie2017-07-051-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we run out of memory while calling _dbus_type_writer_recurse() (which is impossible for most contained types, but can happen for structs and dict-entries), then the memory we allocated in the call to _dbus_message_iter_open_signature() will still be allocated, and we have to free it in order to return to the state of the world prior to calling open_container(). One might reasonably worry that this change can break callers that use this (incorrect) pattern: if (!dbus_message_iter_open_container (outer, ..., inner)) { dbus_message_iter_abandon_container (outer, inner); goto fail; } /* now we know inner is open, and we must close it later */ However, testing that pattern with _dbus_test_oom_handling() demonstrates that it already dies with a DBusString assertion failure even before this commit. This is all concerningly fragile, and I think the next step should be to zero out DBusMessageIter instances when they are invalidated, so that a "double-free" is always detected. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101568 (cherry picked from commit 031aa2ceb3dfff373e7b398dfc5d020d77262512)
* dbus_message_iter_append_basic: Don't leak signature if appending fd failsSimon McVittie2017-07-051-3/+9
| | | | | | | Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101568 (cherry picked from commit 8384e795516066960bb9fcfbfe138f569420edb9)
* dbus_message_append_args_valist: Don't leak memory on inappropriate typeSimon McVittie2017-07-051-0/+1
| | | | | | | | | | Found by source code inspection while trying to debug an unrelated leak. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101568 (cherry picked from commit 6b7bdb105b120b3db312de93af94af1bb6a2a474)
* transport: Don't pile up errors for semicolon-separated componentsSimon McVittie2017-06-271-0/+3
| | | | | | | | | | | If we somehow get an autolaunch address with multiple semicolon-separated components, and one of them fails, then we will hit an assertion failure when we try the next one. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101257 (cherry picked from commit ecdcb86bff42d2bb9cac617bf79f0aa3d47676d9)
* Fix missing dbus_message_unref() in error reply pathShin-ichi MORITA2017-06-271-0/+2
| | | | | | | | | | The error message was leaked when blocking on a pending call after the connection was disconnected. Reviewed-by: Philip Withnall <withnall@endlessm.com> [smcv: re-word commit message] Reviewed-by: Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
* Change _dbus_create_directory to fail for existing directoriesSimon McVittie2017-02-164-3/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 mitigations. 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: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Philip Withnall <withnall@endlessm.com>
* DBusMessage: Fix UB (misaligned access) in call to ↵Marc Mutz2016-10-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _dbus_header_set_field_basic() The const void* 'value' pointer that is passed the address of a uint32_t here eventually ends up in _dbus_marshal_write_basic(), which casts it to a DBusBasicValue, a union type that has an alignment of eight on 64-bit platforms and is therefore more-aligned than the uint32. The read of a value of a more-aligned type through a pointer to a less -aligned type is undefined behaviour. Fix by storing the uint32 in a DBusBasicValue and passing that instead. Found by UBSan: dbus/dbus/dbus-marshal-basic.c:832:14: runtime error: member access within misaligned address 0x7fdb8dac3a04 for type 'const union DBusBasicValue', which requires 8 byte alignment 0x7fdb8dac3a04: note: pointer points here 4a 87 b5 71 01 00 00 00 40 7d 01 00 00 61 00 00 10 3b ac 8d db 7f 00 00 2c 2a 3e 94 db 7f 00 00 ^ #0 0x7fdb9444a2c3 in _dbus_marshal_write_basic dbus/dbus/dbus-marshal-basic.c:832 #1 0x7fdb943d22fb in _dbus_type_writer_write_basic_no_typecode dbus/dbus/dbus-marshal-recursive.c:1605 #2 0x7fdb943d64e9 in _dbus_type_writer_write_basic dbus/dbus/dbus-marshal-recursive.c:2327 #3 0x7fdb943c52a6 in write_basic_field dbus/dbus/dbus-marshal-header.c:318 #4 0x7fdb943c919e in _dbus_header_set_field_basic dbus/dbus/dbus-marshal-header.c:1321 #5 0x7fdb943e1349 in dbus_message_set_reply_serial dbus/dbus/dbus-message.c:1173 Signed-off-by: Marc Mutz <marc@kdab.net> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98035
* _dbus_ensure_standard_fds: new function to ensure std* fds are openSimon McVittie2016-08-122-0/+86
| | | | | | | | | | | | | | | | | This function opens stdin, stdout, stderr pointing to /dev/null if they aren't already open. Optionally, it can also replace whatever is available on those fds with /dev/null. To allow for use in contexts where only async-signal-safe functions should be used, such as between fork() and a following exec(), this function does not use conventional libdbus error handling (which would require malloc). Instead, it sets errno and returns an explanatory string. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97008 Signed-off-by: Simon McVittie <smcv@debian.org> Reviewed-by: Thiago Macieira <thiago@kde.org> (cherry picked from commit 69123a6bd2adabbaec1f770fc4573fc3ed4ceca6)
* Mark WaitingForOK state as unusedSimon McVittie2016-08-121-0/+3
| | | | | | | | | | It should probably be used (see #97298) but the fact that it isn't is breaking compatibility with gcc 6, so apply a quick workaround while we look into what's wrong here. Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97282 (cherry picked from commit 21d61180819c141e779d6ecf9919e62e768b6fd9)
* Merge branch 'dbus-1.10' into dbus-1.10-cidbus-1.10-ciSimon McVittie2016-06-301-0/+20
|\
| * activation: set children oom_score_adj to 0WaLyong Cho2016-06-301-0/+20
| | | | | | | | | | | | | | | | | | | | If dbus is running as systemd service, dbus daemon is running with oom_score_adj -900 by OOMScoreAdjust=-900. And children will also have same value with dbus daemon. To avoid this, set the child itself values after fork () to 0. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=32851 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* | Merge branch 'dbus-1.10' into dbus-1.10-ciSimon McVittie2016-05-183-14/+42
|\ \ | |/
| * Fix ambiguous setup of DBusBabySitter struct member child_handle on Windows.Ralf Habacker2016-05-161-3/+7
| | | | | | | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95191 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
| * On Windows make access to member 'refcount' of struct DBusBabysitter thread ↵Ralf Habacker2016-05-133-7/+32
| | | | | | | | | | | | | | safe. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95191 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
| * Eliminates a race condition accessing DBusBabysitter instance at startup of ↵Ralf Habacker2016-05-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | babysitter() on Windows. Ensure that the babysitter thread already owns its one reference to the babysitter when it starts up, and eliminates the race condition. This patch requires that DBusBabysitter refcounting is thread-safe and is based on an analysis and proposal of Simon Mc Vittie. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95191 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
| * Fix crash in test-spawn unit test app on Windows.Yiyang Fei2016-04-291-1/+2
| | | | | | | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95160 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* | Merge branch 'dbus-1.10' into dbus-1.10-ciSimon McVittie2016-03-023-1/+41
|\ \ | |/
| * Statically assert that the DBusMessageIter struct has no paddingSimon McVittie2016-03-021-0/+5
| | | | | | | | | | | | Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Thiago Macieira <thiago@kde.org> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
| * DBusMessageIter: eliminate padding on 64-bit platformsSimon McVittie2016-03-022-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, 64-bit (LP64 or LLP64) platforms would have had 32 bits of padding between pad2 and pad3. We want to guarantee that an ISO C compiler will copy the entire struct when assigning between structs, but padding is not guaranteed to be copied, so we want to ensure that the struct is "packed". Statically assert that the old ABI is compatible with the new ABI. Reviewed-by: Thiago Macieira <thiago@kde.org> [smcv: change >= to == as Thiago requested] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
| * DBusMessage: assert the properties we need DBusMessageIter to haveSimon McVittie2016-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | We already asserted that DBusMessageIter must be at least as large as DBusMessageRealIter (so that casting DBusMessageIter * to DBusMessageRealIter * does not result in overflowing the stack variable). Also assert that it must have alignment requirements at least as strict as those of DBusMessageRealIter * (so that casting does not increase the required alignment). Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Thiago Macieira <thiago@kde.org> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
| * dbus-internals: add _DBUS_ALIGNOFSimon McVittie2016-03-021-0/+3
| | | | | | | | | | | | | | | | | | This is useful when making static assertions about our types' properties. Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Thiago Macieira <thiago@kde.org> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
| * Revert "Replace $DBUS_USE_TEST_BINARY with $DBUS_TEST_DBUS_LAUNCH"Simon McVittie2016-02-121-4/+4
| | | | | | | | | | This reverts commit 8fd2be6013e3d0ff6a6ff63ea022f9606d9a87c6. This change was intended for 1.11.
| * Revert "Rename function string_array_length() to _dbus_string_array_length() ↵Simon McVittie2016-02-123-24/+15
| | | | | | | | | | | | | | and move it to dbus-internals.c." This reverts commit 1370b44035da90a7fbcebea17074c66c832de0b1. This change was intended for 1.11.
| * Revert "Add new functions _dbus_hash_table_to_array() and ↵Simon McVittie2016-02-122-137/+0
| | | | | | | | | | | | | | _dbus_hash_table_from_array() from related activation code." This reverts commit 610ff8d9646c1bb944bc5e56f22750f1754b308e. This change was intended for 1.11.
| * Add new functions _dbus_hash_table_to_array() and ↵Ralf Habacker2016-02-112-0/+137
| | | | | | | | | | | | | | | | | | _dbus_hash_table_from_array() from related activation code. These functions are required for dbus-run-session. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
| * Rename function string_array_length() to _dbus_string_array_length() and ↵Ralf Habacker2016-02-113-15/+24
| | | | | | | | | | | | | | move it to dbus-internals.c. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
| * Replace $DBUS_USE_TEST_BINARY with $DBUS_TEST_DBUS_LAUNCHSimon McVittie2016-02-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Instead of using $DBUS_USE_TEST_BINARY to control whether to use the hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use $DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we were already doing for $DBUS_TEST_DAEMON. Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
* | Merge branch 'dbus-1.10' into dbus-1.10-ciSimon McVittie2016-02-081-3/+1
|\ \ | |/
| * marshal-validate: run all the tests instead of just the even onesNick Lewycky2016-02-081-3/+1
| | | | | | | | | | | | | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93908 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> [smcv: Re-enable the failing test that Nick disabled, and fix the expected result; the result given by our current implementation is reasonable.]
* | _dbus_test_oom_handling: allow disabling it as documentedSimon McVittie2015-12-021-0/+6
| | | | | | | | | | | | | | | | We documented DBUS_TEST_MALLOC_FAILURES=0 in HACKING, but it didn't actually work: we'd iterate from i=-1 to i=0. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
* | embedded tests: accept and ignore --tap argumentSimon McVittie2015-12-021-1/+1
|/ | | | | | | | | | | | | | This makes them semi-command-line-compatible with a way we can invoke the GLib-based tests to get more useful debug logs. These tests still do not actually produce TAP output yet; I tried implementing that, but it requires changing a lot of noise on stdout to come out of stderr, and there was something weird going on with subprocesses restarting the test numbering which will need further investigation before making that change. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
* Windows _dbus_get_autolaunch_address: don't leak shm_nameSimon McVittie2015-11-181-0/+1
| | | | | Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
* bus-driver: Support returning org.freedesktop.DBus UID and PIDJan Alexander Steffens (heftig)2015-11-173-1/+12
| | | | | | | | | | | Attempting to call SetEnvironment on systemd causes it to inquire about the caller's connection UID and PID. If this check fails, the call is rejected. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92857 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> [smcv: go back to DBUS_ERROR_UNIX_PROCESS_ID_UNKNOWN as the error code for failure to determine the pid]
* Fix recursive loop in backtrace generator on windows.Ralf Habacker2015-11-161-1/+1
| | | | | | | | Backtrace generator called _dbus_warn(), which calls backtrace generator recursively with DBUS_FATAL_WARNINGS=1. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* Fix memory leak in _dbus_win_set_error_from_win_error().Ralf Habacker2015-11-111-6/+1
| | | | | | | | There is no need to make a local (leaked) copy of the message, because dbus_set_error() already makes a copy of its parameters. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* Compile fix on Windows.Ralf Habacker2015-11-041-1/+1
| | | | This commit fixes a regression introduced with commit 04b8a7a772cfa9ae8ea6ce452d1fb7f23e25fd3f.
* Fix warning: variable 'ret' set but not used [-Wunused-but-set-variable].Ralf Habacker2015-11-031-4/+7
| | | | | | | | Only set valid child status in case exit code has been gotten from child process, otherwise signal failure through thread return value. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* Don't use _dbus_warn() for intentionally-skipped testsSimon McVittie2015-11-021-2/+5
| | | | | | | | The tests are run with _dbus_warn() fatal, so if a particular test is not applicable on the current platform, we shouldn't call it. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
View Lorry Controller Status