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
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>
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>
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>
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>
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.
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>
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>
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
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.
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
Qt help files are used by Qt Creator and KDevelop, for example, to support
the development of Qt-based applications and libraries.
Generating api documentation in Qt help format is controlled by two
user specific options named --enable-qt-help and --with-qchdir (autotools)
and -DENABLE_QT_HELP and -DINSTALL_QCH_DIR (cmake).
Marking targets with a component would only be useful if we
marked every target with a component in a consistent way,
but because we don't do that, it's pointless to have it
in just a few places.
For cleaning purpose the event list members are initialized with
WSA_INVALID_EVENT. The cleanup code detects and handles the
case that the event list has been created from calloc ().
The function _dbus_poll() has been split into two functions,
_dbus_poll_events() and _dbus_poll_select(), each containing the
corresponding implementation.
_dbus_poll() now calls the corresponding function.
Some of the command-lines that we print as diagnostics contain newlines,
which will cause warnings or errors under a strict TAP parser (and one of
them wasn't correctly prefixed with '#' anyway). TAP parsers only parse
stdout, not stderr, so we can use stderr for these diagnostic messages.
[smcv: Expand commit message]
Signed-off-by: Simon McVittie <smcv@collabora.com>
