A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: if we are using
traditional eavesdropping with an older dbus-daemon, we'll
confuse everyone else by replying to messages that weren't
intended for us. If we are using the new Monitoring
interface (since 1.9.12), the same still applies, but in
addition, the dbus-daemon will disconnect us for not being
a well-behaved monitor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Because the context parameter is dereferenced several times in related code without a null check,
we need to make sure to have a valid context.
Reported by Coverity: CID 54764: Dereference after null check (FORWARD_NULL)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reply message was not unreferenced when GetConnectionCredentials
handler was successful.
Signed-off-by: Jacek Bukarewicz <j.bukarewicz@samsung.com>
[smcv: changed bus_message_unref() to dbus_message_unref()]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91008
This is more robust against broken setups where we run out
of memory or cannot read /dev/urandom.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, this would always succeed, but might use
weak random numbers in rare failure cases. I don't think
these UUIDs are security-sensitive, but if they're generated
by a PRNG as weak as rand() (<= 32 bits of entropy), we
certainly can't claim that they're universally unique.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This can currently only fail from OOM, but I'm about to make
it possible to fail from insufficient entropy.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This can currently only fail due to OOM, but I'm about to
make it possible to fail for other reasons.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: correct failure to set error in one case; document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
indirectly dependent on high-quality pseudo-random numbers
whereas EXTERNAL authentication (credentials-passing)
is mediated by the kernel and cannot be faked.
On Windows, EXTERNAL authentication is not available,
so we continue to use the hard-coded default (all
authentication mechanisms are tried).
Users of tcp: or nonce-tcp: on Unix will have to comment
this out, but they would have had to use a special
configuration anyway (to set the listening address),
and the tcp: and nonce-tcp: transports are inherently
insecure unless special steps are taken to have them
restricted to a VPN or SSH tunnelling.
Users of obscure Unix platforms (those that trigger
the warning "Socket credentials not supported on this Unix OS"
when compiling dbus-sysdeps-unix.c) might also have to
comment this out, or preferably provide a tested patch
to enable credentials-passing on that OS.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Appending &some as DBUS_TYPE_INT64, DBUS_TYPE_UINT64 or DBUS_TYPE_DOUBLE,
where "some" is an int, reads beyond the bounds of that variable.
Use a zero-filled DBusBasicValue instead.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=30350
It didn't have many users anyway, and I've replaced them with the
DBUS_SOCKET_IS_VALID macro.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The former is Unix-specific, the latter is also portable to Windows.
On Unix, they're really the same thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This requires generic support for keying hash tables by DBusPollable:
there are already implementations for int and uintptr_t keys, but not
for "int or uintptr_t depending on platform", which is what
DBusPollable now means.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
This is only used on Windows, and wasn't even a particularly abstract
abstraction.
I've removed DBUS_SOCKET_IS_INVALID in favour of DBUS_SOCKET_IS_VALID
because I prefer to avoid double-negatives.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is all trivial right now, but will become significant when we
change DBusSocket into a type-safe struct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: remove unneeded and invalid dbus-sysdeps.h from public header;
make prototype of _dbus_socketpair() consistent; undo conversion
of getaddrinfo result from int to SOCKET; don't call
_dbus_return_val_if_fail() from internal function]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
indirectly dependent on high-quality pseudo-random numbers
whereas EXTERNAL authentication (credentials-passing)
is mediated by the kernel and cannot be faked.
On Windows, EXTERNAL authentication is not available,
so we continue to use the hard-coded default (all
authentication mechanisms are tried).
Users of tcp: or nonce-tcp: on Unix will have to comment
this out, but they would have had to use a special
configuration anyway (to set the listening address),
and the tcp: and nonce-tcp: transports are inherently
insecure unless special steps are taken to have them
restricted to a VPN or SSH tunnelling.
Users of obscure Unix platforms (those that trigger
the warning "Socket credentials not supported on this Unix OS"
when compiling dbus-sysdeps-unix.c) might also have to
comment this out, or preferably provide a tested patch
to enable credentials-passing on that OS.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
This patch is based on the fix for 'Field reader.array_len_offset is
uninitialized'
Reported by Coverity: CID 54754, 54772, 54773: Uninitialized scalar
variable (UNINIT)
[smcv: also re-order how the class is set when we recurse, so that
the sub-reader's class doesn't end up NULL]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
This reverts commit 21a7873f20.
This appears to cause a segfault, presumably resulting from something
assuming that reader_init() would not reinitialize all fields:
#0 0x00007ffff7b74777 in _dbus_type_reader_get_current_type (reader=reader@entry=0x7fffffffda50) at .../dbus/dbus-marshal-recursive.c:791
#1 0x00007ffff7b719d0 in _dbus_header_cache_check (header=<optimized out>)
at .../dbus/dbus-marshal-header.c:209
#2 0x00007ffff7b719d0 in _dbus_header_cache_check (header=header@entry=0x624658, field=field@entry=6) at .../dbus/dbus-marshal-header.c:250
#3 0x00007ffff7b72884 in _dbus_header_get_field_basic (header=header@entry=0x624658, field=field@entry=6, type=type@entry=115, value=value@entry=0x7fffffffdbd8) at .../dbus/dbus-marshal-header.c:1365
#4 0x00007ffff7b7d8c2 in dbus_message_get_destination (message=message@entry=0x624650) at .../dbus/dbus-message.c:3457
#5 0x00007ffff7b67be6 in _dbus_connection_send_preallocated_unlocked_no_update (connection=connection@entry=0x6236d0, preallocated=0x0,
preallocated@entry=0x6234c0, message=message@entry=0x624650, client_serial=client_serial@entry=0x7fffffffdcbc)
at .../dbus/dbus-connection.c:2017
This patch is based on the fix for 'Field reader.array_len_offset is uninitialized'
Reported by Coverity: CID 54754, 54772, 54773: Uninitialized scalar variable (UNINIT)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
