This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
With the minimum version set to 3.4, none of the policies need to be set explicitly to the `NEW` behavior.
Each of the policies removed here was introduced before CMake version 3.4.
By default then, each of them will be set to NEW automatically.
This is part of the behavior of cmake_minimum_required.
The cmake_policy commands are therefore redundant and have been removed.
In other projects I've found that having a separate file that only
lists the release steps makes them easier to check.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We're considering MSVC 2015 to be sufficiently close to C99 for our
purposes, and we now have CI for it, so we can easily check whether any
desired C99 feature works. Other pre-C99 compilers are obsolete.
Resolves: dbus#404
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is really three separate test-cases: one for traditional
activation as a direct child process of the dbus-daemon, and two for
traditional activation (successful and failing) via the setuid
dbus-daemon-launch-helper on Unix.
The ones where activation succeeds extremely slow, as a result of the
instrumentation for simulating malloc() failures combined with a large
number of memory operations, particularly when using AddressSanitizer.
Splitting up "OOM" tests like these has a disproportionately good impact
on the time they take, because the simulated malloc() failure
instrumentation repeats the entire test making the first malloc() fail,
then making the second malloc() fail, and so on. For allocation failures
in the second half of the test, this means we repeat the first half of
the test with no malloc() failures a very large number of times, which
is not a good use of time, because we already tested it successfully.
Even when not using the "OOM" instrumentation, splitting up these tests
lets them run in parallel, which is also a major time saving.
Needless to say, this speeds up testing considerably. On my modern but
unexceptional x86 laptop, in a typical debug build with Meson, the old
dispatch test took just over 21 minutes, which drops to about 40 seconds
each for the new normal-activation and helper-activation tests (and for
most of that time, they're running in parallel, so the wall-clock time
taken for the whole test suite is somewhere around a minute).
In a debug build with Meson, gcc and AddressSanitizer, the old dispatch
test takes longer than my patience will allow, and the new separate
tests take about 5-6 minutes each. Reduce their timeout accordingly, but
not as far as the default for slow tests (5 minutes) to allow some
headroom for AddressSanitizer or slower systems.
The failed-helper-activation test is almost instantaneous, and no longer
needs to be marked as slow.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a Linux user namespace, it is possible that we are uid 0 but are
unable to switch to some other uid like DBUS_USER or DBUS_TEST_USER,
because the other uid is not "mapped" in the user namespace, resulting
in setuid() or setresuid() failing with EINVAL "Invalid argument".
For example, it's easy for this to happen when running under the
bubblewrap tool.
Try to drop privileges in a child process, and skip the test if we
are unable to do so.
Resolves: dbus#407
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're running in a sandbox, we might not have write access to
oom_score_adj. In the common case where we don't have any special
protection from the OOM-killer, we can detect that with only read
access, and skip the part where we open it for writing.
(We would also not have write access to oom_score_adj if we're running
with elevated Linux capabilities while not root, but that should never
actually happen for dbus-daemon-launch-helper, which is setuid root
for production use or has no capabilities during unit-testing.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
_dbus_warn() normally only logs a warning, but can be made fatal by
environment variables. In particular, we do that during unit testing,
which can result in a build-time test failure if dbus is built in a
sandbox environment that prevents write access.
_dbus_log() does only the logging part of _dbus_warn(), which seems
more appropriate here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The comment refers to the nul-padding of sockaddr_un member sun_path and
using an addrlen of sizeof(sockaddr_un). There is not much need to
document an old now "broken" behaviour.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Split _dbus_server_listen_platform_specific() to handle unix listenable
address independently, allowing Windows support in following commit.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Split _dbus_transport_open_unix_socket() to leave the "unixexec:"
handling to the unix-specific unit.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Split out the Unix socket handling from open_platform_specific(),
enabling "unix:" connectable addresses on Windows in next patch.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
