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>
The overall problem here is that DBusCounter is indirectly linked
to a DBusConnection, but is not actually guaranteed to be protected by
that connection's mutex; and a DBusMessage can carry a reference to the
DBusCounter, resulting in freeing that DBusMessage having an effect on
the DBusCounter.
Making the refcount atomic would not be a sufficient fix, since it would
not protect the notify function: _dbus_counter_notify() could be called
indirectly by dbus_message_unref(), in an arbitrary thread that does not
hold the DBusConnection's lock, at the same time that the holder
of the DBusConnection lock calls _dbus_transport_set_max_message_size().
[smcv: added commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89297
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The other code paths that ref or unref a transport are protected by
the DBusConnection's lock. This function already used that lock,
but for a narrower scope than the refcount manipulation.
live_messages_notify() could be triggered by unreffing messages
that originated from the same connection in a different thread.
[smcv: added commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90312
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
unistd.h and sleep() are normally Unix-specific, although mingw also provides them.
The Windows C runtime documents _environ as its equivalent of Unix environ.
https://bugs.freedesktop.org/show_bug.cgi?id=90089
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
