When "activating" systemd, handle its special case better

When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.

In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.

In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix build error: unused-result

Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix dbus-daemon crash due to invalid service file

dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
NEWS for 1.6.x
CVE-2013-2168: _dbus_printf_string_upper_bound: copy the va_list for each use

Using a va_list more than once is non-portable: it happens to work
under the ABI of (for instance) x86 Linux, but not x86-64 Linux.

This led to _dbus_printf_string_upper_bound() crashing if it should
have returned exactly 1024 bytes. Many system services can be induced
to process a caller-controlled string in ways that
end up using _dbus_printf_string_upper_bound(), so this is a denial of
service.

Reviewed-by: Thiago Macieira <thiago@kde.org>
Add a test-case for CVE-2013-2168

Reviewed-by: Thiago Macieira <thiago@kde.org>
[build system adjusted to compile it even if we don't have GLib -smcv]
Prepare embargoed release for tomorrow
Start 1.6.13
Merge branch 'dbus-1.6'

Conflicts:
	NEWS
	configure.ac
_dbus_system_logv: copy the va_list here too

This would crash if HAVE_SYSLOG_H is defined, HAVE_DECL_LOG_PERROR
is false, and the platform calling convention is that va_list is a
struct. Verified on Linux by undefining HAVE_DECL_LOG_PERROR.

Reviewed-by: Colin Walters <walters@verbum.org>
Revert "start spec 0.22 development"

This reverts commit 82b3d94ab10f16e6c6c18eb3bc76594cd63e3854.
Fix an incorrect comment

_dbus_threads_lock_platform_specific() is implemented on Windows now.
NEWS
Move libdbus-init-win.cpp to its own convenience library

Otherwise libdbus-1 ends up linked as if it contained C++, even
on Unix, where it doesn't; in turn, that makes it export all the
underscore-prefixed symbols that aren't meant to be exported.

Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: David Zeuthen <davidz@redhat.com>
Prepare 1.7.4 for tomorrow
Add release name for 1.6.12
Start on 1.7.5, add release name for 1.7.4
Fix Werror=unused-function if build without X11

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65712
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
start spec 0.22 development
Replace individual global-lock variables with an array of DBusRMutex *

This means we can use a much simpler code structure in data-slot
allocators: instead of giving them a DBusRMutex ** at first-allocation,
we can just give them an index into the array, which can be done
statically.

It doesn't make us any more thread-safe-by-default - the mutexes will
only actually be used if threads were already initialized - but it's
substantially better than nothing.

These locks really do have to be recursive: for instance,
internal_bus_get() calls dbus_bus_register() under the bus lock,
and dbus_bus_register() can call _dbus_connection_close_possibly_shared(),
which takes the bus lock.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Anas Nashif <anas.nashif@intel.com>