As a general design principle, strings that we aren't going to modify
should usually be const. When compiling with -Wwrite-strings, quoted
string constants are of type "const char *", causing compiler warnings
when they are assigned to char * variables.
Unfortunately, we need to add casts in a few places:
* _dbus_list_append(), _dbus_test_oom_handling() and similar generic
"user-data" APIs take a void *, not a const void *, so we have
to cast
* For historical reasons the execve() family of functions take a
(char * const *), i.e. a constant pointer to an array of mutable
strings, so again we have to cast
* _dbus_spawn_async_with_babysitter similarly takes a char **,
although we can make it a little more const-correct by making it
take (char * const *) like execve() does
This also incorporates a subsequent patch by Thomas Zimmermann to
put various string constants in static storage, which is a little
more efficient.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This avoids confusion with the meaning of "release" used by
AX_IS_RELEASE. AX_IS_RELEASE is about facts about the source tree,
namely the distinction between releases (tags) and random snapshots.
The build variants in .travis.yml are about facts about the build
being done, namely the distinction between production and
debug/developer builds.
Production builds are sometimes referred to as "release builds",
for example in typical CMake and MSVC build environments, but a
different term seems better here.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This patch fixes warnings from '-Wsuggest-attribute=noreturn'. We cannot
enable it unconditionally as it would break libtool.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: omit the part involving environ, which was more involved]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: split out from a larger commit]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This path removes the obsolete configure option
'--disable-compiler-optimisations'. Users can control compiler flags
by setting CFLAGS, CXXFLAGS, etc in the build environment.
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
Several internal functions are not used on Windows. This patch
hides them behind DBUS_WIN.
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
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: add space after cast, that is our coding style]
Reviewed-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This patch adds 'void' to function declarations without parameters.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: fix coding style while we're touching these lines anyway]
Reviewed-by: Simon McVittie <smcv@debian.org>
The command-line option '--enable-debug' controls the debugging and
profiling flags of the build. Debugging is disabled by default and only
enabled on developer builds. Profiling is always disabled. Both options
can be overridden from the command line (e.g., for profiling of release
builds).
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: remove trailing whitespace from new lines]
Reviewed-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This isn't security-related, just defensive programming: if
dbus-daemon wasn't run with --systemd-activation, then there is no
reason why systemd would legitimately send us this signal, and if it
does we should just ignore it.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98157
Specifically, this will allow ActivationFailure messages from our
own uid or from root, but reject them otherwise, even if the bus
configuration for who can own org.freedesktop.systemd1 is entirely
wrong due to something like CVE-2014-8148.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98157
In principle this could lead to arbitrary memory overwrite via
a format string attack in the message received from systemd,
resulting in arbitrary code execution.
This is not believed to be an exploitable security vulnerability on the
system bus in practice: it can only be exploited by the owner of the
org.freedesktop.systemd1 bus name, which is restricted to uid 0, so
if systemd is attacker-controlled then the system is already doomed.
Similarly, if a systemd system unit mentioned in the activation failure
message has an attacker-controlled name, then the attacker likely already
has sufficient access to execute arbitrary code as root in any case.
However, prior to dbus 1.8.16 and 1.9.10, due to a missing check for
systemd's identity, unprivileged processes could forge activation
failure messages which would have gone through this code path.
We thought at the time that this was a denial of service vulnerability
(CVE-2015-0245); this bug means that it was in fact potentially an
arbitrary code execution vulnerability.
Bug found using -Wsuggest-attribute=format and -Wformat-security.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98157
If it is set (i.e. if an LSM is in use) this will make it appear in
various places in log output.
With SELinux, for example, this appends something like:
label="system_u:object_r:unlabeled_t:s0"
This commit partially rearranges the code which sets the loginfo string,
so that it consistently puts a space between fields, and not one at the
end.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68212
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This clarifies
Activating via systemd: service name='com.example.Example'
unit='example.service'
to
Activating via systemd: service name='com.example.Example'
unit='example.service' requested by ':1.23' (uid 1000 pid 123
comm "whatever-activat")
Similarly for the non-systemd code paths.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68212
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Install them to $(datadir)/xml/dbus-1, which seems to be the standard
location for installed DTDs. This means that developers can use them to
validate their introspection XML, and sysadmins can use them to validate
their bus configuration files.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89011
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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
This is widely used in practice (especially by GLib — just look at files
in /usr/share/dbus-1/interfaces/), and there is no reason not to allow
it. Update the specification, introspection DTD and XSL file to allow
and represent it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86162
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This adds a space in the output between ‘annotation’ and the key of the
annotation. A Saturday afternoon cosmetic fix.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86162
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
They used to be needed, but are not needed any more, and we were
never completely consistent about including them in any case.
Signed-off-by: Simon McVittie <smcv@debian.org>
_dbus_warn() now calls _dbus_logv() which always logs the pid and
prints a newline anyway.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97009
In particular this means the test suite won't spam the Journal
any more.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97009
Like --fork and --nofork, these override what the configuration says.
Use --syslog-only to force the systemd services to log to the Journal
(via syslog, which means we see the severity metadata) instead of
testing sd_booted() in the configuration implementation.
Signed-off-by: Simon McVittie <smcv@debian.org>
This means that dbus-daemon will log something like
dbus-daemon[123]: Unable to add reload watch to main loop
to syslog and/or stderr according to its configuration, while other
libdbus users will print something like this to stderr:
dbus[4567]: arguments to dbus_foo() were incorrect, assertion
"connection != NULL" failed at file dbus-foo.c line 123.
This is normally a bug in some application using the D-Bus library.
This slightly changes the meaning of the argument to _dbus_warn()
and _dbus_warn_check_failed. Previously, a trailing newline was
expected, and a missing newline would have resulted in incorrect
output. Now, a newline is supplied automatically by the
library (like g_warning()), and messages that end with a newline will
result in an unnecessary extra newline in output.
This extra newline is harmless, so I'm not going to change all the
callers immediately.
Signed-off-by: Simon McVittie <smcv@debian.org>
_dbus_log() and _dbus_logv() are always the right functions to call now.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97009
This changes the behaviour of _dbus_logv() if _dbus_init_system_log() was
not called. Previously, _dbus_logv() would always log to syslog;
additionally, it would log to stderr, unless the process is dbus-daemon
and it was started by systemd. Now, it will log to stderr only,
unless _dbus_init_system_log() was called first.
This is the desired behaviour because when we hook up
_dbus_warn_check_failed() to _dbus_logv() in the next commit, we don't
want typical users of libdbus to start logging their check failures to
syslog - we only want the dbus-daemon to do that.
In practice this is not usually a behaviour change, because there was
only one situation in which we called _dbus_logv() without first calling
_dbus_init_system_log(), namely an error while parsing configuration
files. Initialize the system log "just in time" in that situation
to preserve existing behaviour.
Signed-off-by: Simon McVittie <smcv@debian.org>
