- 28 Sep, 2020 2 commits
-
-
Simon McVittie authored
disable fork-malloc-exec for non-glibc-systems See merge request dbus/dbus!181
-
Jean-Louis Fuchs authored
Calling malloc() after fork is undefined behaviour if the process is multi-threaded. locks held by a thread on fork() will never be released. malloc() is usally protected by a lock and can therefore deadlock. glibc is known not to deadlock in this case. This commit does not rule out other problems on glibc-systems, but fixes an issue on musl-libc-systems. Only restricting to async-signal safe functions between fork() and exec() prevents undefined behaviour for sure. See signal-safety(7).
-
- 24 Sep, 2020 1 commit
-
-
Simon McVittie authored
CMake: allow traditional activation to be disabled See merge request dbus/dbus!159
-
- 23 Sep, 2020 4 commits
-
-
Ralf Habacker authored
Traditional activation is enabled/disabled with the cmake configure parameter -DENABLE_TRADITIONAL_ACTIVATION, which is enabled by default. This was added to the Autotools build system as part of dbus/dbus!107 but until now was not possible to disable when building with CMake.
-
Ralf Habacker authored
cmake: move up checking DBUS_ENABLE_EMBEDDED_TESTS from subdir test/name-test to test See merge request dbus/dbus!177
-
Ralf Habacker authored
The whole file is only added with the mentioned variable set, so it can also be skipped completly one level up.
-
Simon McVittie authored
cmake: install dbus-daemon-launch-helper Closes #310 See merge request dbus/dbus!175
-
- 22 Sep, 2020 1 commit
-
-
Ralf Habacker authored
Previously it was built on Unix platforms, but not installed. This would prevent traditional activation on the system bus (on Linux without systemd or non-Linux, or for services without SystemdService), which requires the activation helper. Because the executable is an internal implementation detail of how traditional activation is implemented on Unix, it is not exported to the generated cmake support files. Resolves: dbus#310
-
- 21 Sep, 2020 1 commit
-
-
Simon McVittie authored
spec: Update recommendations for DBUS_COOKIE_SHA1 timeouts See merge request dbus/dbus!171
-
- 07 Sep, 2020 1 commit
-
-
Simon McVittie authored
This had two issues that could damage interoperability. First, the spec wording suggested that any cookie that had not been deleted was suitable for use in authentication. However, this introduces a race condition, which is called out in comments in both the reference implementation and GDBus: the newest cookie might be less old than the arbitrary lifetime when authentication *begins*, but older than the lifetime at the time authentication *ends*. As a result, we need a grace period during which an old cookie will still be accepted, but a newer cookie exists and will be used for new authentication operations. Second, the spec wording implied that the arbitrary timeouts were completely up to the implementor. However, GLib bug https://gitlab.gnome.org/GNOME/glib/-/issues/2164 indicates that they need to be reasonably compatible: in particular, GDBus servers historically didn't allocate new cookies until 10 minutes had passed, but libdbus clients would decline to use a cookie older than 5 minutes, causing authentication to fail if the gdbus-server test-case (in which GDBus and libdbus clients connect to a GDBus server) happened to take longer than 5 minutes to run. While I'm here, also be consistent about calling the secrets "cookies" (consistent with the name of the mechanism) rather than "keys" (which is what they are called in libdbus' dbus-keyring.c). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 19 Aug, 2020 1 commit
-
-
Simon McVittie authored
tests: On Unix, include <netinet/in.h> for IPPROTO_TCP See merge request dbus/dbus!167
-
- 14 Aug, 2020 1 commit
-
-
Simon McVittie authored
Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests are enabled (which suggests that no FreeBSD user has run those tests successfully). We already include <netinet/in.h> in other places with no conditions or checks other than "is Unix", so apparently it's portable enough that specifically testing for its presence is not necessary. POSIX requires it to exist. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 02 Jul, 2020 2 commits
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 01 Jul, 2020 2 commits
-
-
Simon McVittie authored
userdb: Reference-count DBusUserInfo, DBusGroupInfo Closes #305 See merge request dbus/dbus!166
-
Simon McVittie authored
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 ...
-
- 30 Jun, 2020 1 commit
-
-
Simon McVittie authored
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>
-
- 15 Jun, 2020 1 commit
-
-
Simon McVittie authored
Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNC Closes #304 See merge request dbus/dbus!165
-
- 12 Jun, 2020 1 commit
-
-
Andy Fiddaman authored
-
- 10 Jun, 2020 11 commits
-
-
Simon McVittie authored
cmake: Fix installed files See merge request dbus/dbus!155
-
Systemd user support is controlled by the cmake variable ENABLE_USER_SESSION, which and WITH_SYSTEMD_USERUNITDIR to specify a custom installation location. If WITH_SYSTEMD_USERUNITDIR is not specified, the related install path is determined from an installed systemd package, if present. This was added to the Autotools build system as part of fd.o#61301, but until now was not possible to enable when building with CMake.
-
Previously, only the Autotools build system could do this. This commit includes most of the same features as in the Autotools build, although not the user-session semantics, which will be added separately. Systemd support is controlled by the cmake variable ENABLE_SYSTEMD, which can have the values OFF, ON and AUTO, the latter enabling support by default if the required libraries are available. With WITH_SYSTEMD_SYSTEMUNITDIR a custom installation location can be specified. If it is not specified, the related install path is determined from the installed systemd package, if present.
-
check_auto_option() checks the values given to an auto-option and prints a fatal error in case of invalid combinations.
-
-
This means we apply GNUInstallDirs' various special cases when the prefix is /, /usr or something starting with /opt; these are not applied when installing to CMAKE_INSTALL_<dir>. See https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#special-cases
-
-
Simon McVittie authored
Normalize C source files to end with exactly one newline See merge request dbus/dbus!162
-
Simon McVittie authored
Some editors automatically remove trailing blank lines, or automatically add a trailing newline to avoid having a trailing non-blank line that is not terminated by a newline. To avoid unrelated whitespace changes when users of such editors contribute to dbus, let's pre-emptively normalize all files. Unlike more intrusive whitespace normalization like removing trailing whitespace from each line, this seems unlikely to cause significant issues with cherry-picking changes to stable branches. Implemented by: find . -name '*.[ch]' -print0 | \ xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g' Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
dbus-protocol.h: fix DBUS_ERROR_SPAWN_NO_MEMORY comment See merge request dbus/dbus!163
-
Marc-André Lureau authored
Although this error seems to be unused (DBUS_ERROR_NO_MEMORY is used instead), let's correct the comment. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com>
-
- 02 Jun, 2020 4 commits
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Reproduces: #294 Reproduces: CVE-2020-12049 Reproduces: GHSL-2020-057 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
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. Reported-by: Kevin Backhouse, GitHub Security Lab Fixes: dbus#294 Fixes: CVE-2020-12049 Fixes: GHSL-2020-057
-
- 01 Jun, 2020 1 commit
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 29 May, 2020 3 commits
-
-
Simon McVittie authored
CI: run cross compiled tests Closes #296 See merge request dbus/dbus!158
-
Ralf Habacker authored
This helps to detect incorrect settings.
-
Ralf Habacker authored
Before building a wine prefix is created and search pathes for binaries are configured in the wine prefix. This commit adds a new shell variable 'ci_runtime' for specifing the type of compiler support library which defaults to static for now.
-
- 28 May, 2020 1 commit
-
-
Simon McVittie authored
Let Wine display the correct file name and line numbers for backtraces See merge request dbus/dbus!104
-
- 16 May, 2020 1 commit
-
-
Ralf Habacker authored
Wine currently only supports the symbol formats STABS and DWARF 2, but not the other versions, with STABS providing the most information and being the first choice. Since we already use the cmake variable DBUS_USE_WINE for running tests under Wine, we also use it to activate the special symbol format. Closes dbus/dbus/#133
-