Checking the uid of the user seat also works if elogind is used. Add
this as an option to the build and make it mutually exclusive with
enabling systemd.
Fix an off by one error which could produce a tv_nsec value of
1'000'000'000. The valid tv_nsec range is [0, 999,999,999], see
https://en.cppreference.com/w/c/chrono/timespec for reference.
Passing a timespec with a tv_nsec value of 1'000'000'000 to
pthread_cond_timedwait has been observed to cause it to return an error
code which in turn makes the DBUS library abort the application when
compiled with asserts enabled (by PTHREAD_CHECK).
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/556
Reviewed-by: Simon McVittie <smcv@collabora.com>
14.2 reaches end-of-life in September, and our 14.2-based image has a
sufficiently small amount of space available that it fails to upgrade
now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We recommend that assertions are disabled in production builds of dbus,
which means that they are "cheap" to add to development builds as
"executable documentation" for our assumptions.
Lower-level code assumes that timeouts must be either -1 to block
forever, or non-negative to block for a finite time (but possibly 0,
to poll without blocking).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were checking for -1 as the special-cased "block forever"
value, but as noted on dbus!524 it is a programming error to call
_dbus_condvar_wait_timeout() with any negative timeout.
Throughout DBusConnection the timeout is in fact constrained to be >= -1
(non-negative to have a timeout, or exactly -1 to block forever) but
checking for non-negative is presumably no more expensive than checking
for exactly -1, so let's be a little more defensive here, to make it
more obvious that we're doing this correctly.
This is the only caller of _dbus_condvar_wait_timeout() in our codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As noted in dbus!524 by source code inspection, the Unix/pthread
implementation assumes that the timeout is non-negative and does not
support a mode where it blocks forever (which we normally represent as
a negative timeout, like POSIX poll(2)).
This means that it would be a programming error if we ever call
this with a negative timeout, so put an equivalent assertion in the
platform-independent layer. We recommend that assertions are disabled in
production builds, so it's "cheap" to have a redundant assertion here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We should never allocate a DBusTimeout with a negative timeout set:
if we want to wait forever for an event to happen, that's represented
by the absence of a DBusTimeout.
This ensures that code in DBusConnection can safely assume that the
timeout retrieved from a DBusTimeout will always be in its allowed range
(-1 to INT_MAX inclusive).
I've checked that all current callers get this right.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Getting into the `if (timeout == NULL)` block means that
timeout_milliseconds == -1, so it doesn't make sense to do arithmetic on it.
Pass -1 instead of a nonsensical value in this case
It's unexpected to have DBUS_SESSION_SOCKET_DIR take different values in
CMakeCache.txt, which lists the variables that are available to be set
by the caller, and in config.h, which makes their final values available
to the C code. If DBUS_SESSION_SOCKET_DIR is empty and we are running
on Unix, set it to its dynamically-chosen fallback before storing it in
the cache.
[smcv: Add commit message]
Co-authored-by: Simon McVittie <smcv@collabora.com>
When the ancestor of this code was introduced in 2003 (commit e45e4382),
it was presumably most common to have these variables either unset, or
set to a value that is system-wide and remains valid in the long term,
such as /tmp or /var/tmp.
However, on modern systems they are sometimes set to a value that is
itself temporary, for example /var/folders/${some_long_path}/T on macOS,
or user-specific, for example /tmp/user/$(id -u) on Linux with
libpam-tmpdir. These values are certainly not useful to hard-code into
libdbus and dbus-daemon during installation: they will not be usable
when running dbus-related programs after a reboot or as a different user.
So, instead of assuming TMPDIR, TEMP and TMP remain valid long-term,
we now hard-code /tmp as our default.
As before, system integrators can override this default with
`-Dsession_socket_dir=...` (Meson) or `-DDBUS_SESSION_SOCKET_DIR=...`
(CMake) if a different directory is more appropriate than /tmp.
However, system integrators should note that because AF_UNIX paths have
a relatively short length limit (typically 108 bytes), a short path is
better than a long path in this context.
Resolves: dbus/dbus#551
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it a bit easier to override both temporary directories used
for sockets to the same place. If a directory is suitable for production
use for the session bus' temporary sockets, the same directory is very
likely to be suitable for build-time tests as well, and using that
directory for both purposes makes the tests more realistic.
The non-default CMake build system already did the equivalent of this:
it doesn't have an equivalent of test_socket_dir, and setting its
equivalent of session_socket_dir affects both.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it a little bit clearer that it's OK for the default value
to be Unix-specific. The CMake build system already has the equivalent
of this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is not used on Windows (in fact it's only used in the
dbus-cleanup-sockets(1) tool) so it's OK for it to have a value like /tmp
that would be inappropriate on Windows. Make that more obvious.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it more obvious that it is currently only used on Unix,
and therefore it's OK for it to have a default that wouldn't work
on Windows.
The non-default CMake build system already didn't set the variable when
building for Windows.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Meson build-time tests are run with `meson test` instead, but let's
say "automated tests" generically, rather than a specific command.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Commit 54d26df5 "config: change default auth_timeout to 5 seconds"
reduced the hard-coded default from 30 to 5 seconds, and the
commented-out informational copy of this information in system.conf
reflected that.
Commit 02e1ddf9 'Revert "config: change default auth_timeout to 5 seconds"'
subsequently increased hard-coded default back to 30 seconds, but did
not update the commented-out version in this file.
See also CVE-2014-3639, fd.o #80919, fd.o #86431.
Fixes: 1a36f983 "Document default limits in system.conf.in"
Fixes: 02e1ddf9 'Revert "config: change default auth_timeout to 5 seconds"'
Signed-off-by: Simon McVittie <smcv@collabora.com>
We recommend the Meson build system for all target operating systems
other than Windows. We do try to keep CMake builds operational on Linux
to make life easier for developers, but the `opensuse cmake debug` job,
which runs by default, is sufficient for that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was broken for a while (see dbus#462, dbus!426, dbus!429, dbus!512)
but now it works again. Let's not allow it to regress without someone
noticing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're building a dependency as a fallback subproject, we don't want
to be responsible for installing it as a shared library. Anyone wanting
shared libraries should install the dependencies separately.
Ideally we'd do this with MSVC too, but that doesn't currently link
successfully (dbus#549).
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're falling back to building a local copy of expat, running or
debugging its unit tests is out-of-scope for maintenance of dbus.
In fact this is the default in the meson_options.txt provided by
WrapDB[1], but explicit is better than implicit.
[1] https://github.com/mesonbuild/wrapdb/blob/HEAD/subprojects/packagefiles/expat/meson_options.txt
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of them fail when run on Windows, and debugging the test suite
for a subproject is out-of-scope for dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
