These function arguments are arranged in the obvious order from
conceptually largest to smallest: (bus name, path, interface, method).
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a D-Bus-Specification-compliant message bus, the owner of a well-known
name is a unique name. However, ibus has its own small implementation
of a message bus (src/ibusbus.c) in which org.freedesktop.IBus is
special-cased to also have itself as its owner (like org.freedesktop.DBus
on a standard message bus), and connects to that bus with the
G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION flag. The ability to do
this regressed when CVE-2024-34397 was fixed.
Relax the checks to allow the owner of a well-known name to be any valid
D-Bus name, even if it is not syntactically a unique name.
Fixes: 683b14b9 "gdbus: Track name owners for signal subscriptions"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3353
Bug-Debian: https://bugs.debian.org/1070730
Bug-Debian: https://bugs.debian.org/1070736
Bug-Debian: https://bugs.debian.org/1070743
Bug-Debian: https://bugs.debian.org/1070745
Signed-off-by: Simon McVittie <smcv@debian.org>
Otherwise a malicious connection on a shared bus, especially the system
bus, could trick GDBus clients into processing signals sent by the
malicious connection as though they had come from the real owner of a
well-known service name.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>
We will use this in a subsequent commit to prevent signals from an
impostor from being delivered to a subscriber.
To avoid message reordering leading to misleading situations, this does
not use the existing mechanism for watching bus name ownership, which
delivers the ownership changes to other main-contexts. Instead, it all
happens on the single thread used by the GDBusWorker, so the order in
which messages are received is the order in which they are processed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a connection has two signal subscriptions active for the same signal,
one with arg0 matching and one without, a signal which doesn’t contain
an arg0 value (i.e. `g_dbus_message_get_arg0()` returns `NULL`) will
cause `NULL` to be passed to `strcmp()` when checking for a match
against the signal subscription which *has* arg0 matching, causing a
crash.
Fix that by adding the obvious `NULL` check, and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3342
scan-build thinks that `data` could be leaked. It’s not, though; it’s
passed as the `user_data` to `g_dbus_connection_register_object()` along
with its free function.
Try and persuade scan-build that there’s no leak by annotating the
transfer.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will become confusing when we start tracking the owner of a
well-known-name sender, and it's redundant anyway. Instead, track the
1 bit of data that we actually need: whether it's a well-known name.
Strictly speaking this too is redundant, because it's syntactically
derivable from the sender, but only via extra string operations.
A subsequent commit will add a data structure to keep track of the
owner of a well-known-name sender, at which point this boolean will
be replaced by the presence or absence of that data structure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional change, just removing some nesting. The check for whether
signal_data->subscribers is empty changes from a conditional that tests
whether it is into an early-return if it isn't.
A subsequent commit will add additional conditions that make us consider
a SignalData to be still in use and therefore not eligible to be removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional changes, except that the implicit ownership-transfer
for the rule field becomes explicit (the local variable is set to NULL
afterwards).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Subsequent changes will need to access these data structures from
on_worker_message_received(). No functional change here, only moving
code around.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There were a couple of functions in `GDBusConnection` which take a
`user_data` argument, but which then leak it if they error out early.
A true positive spotted by scan-build!
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
There were some error paths where it wasn’t set, returning an
uninitialised value to the caller.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
It can cause failures for shared connection objects.
What can currently happen is this:
1. A user starts to asynchronously create a proxy object
2. A user starts to asynchronously create another proxy object
At this point, the asynchronous initialization for the two proxy objects
share the not yet initialized connection object.
3. While the shared connection objected is created, the user cancels the
creation with the supplied cancellable from the fist proxy object.
4. initable_init caches the canceled error and marks the connection as
initialized.
5. The initialization of the second proxy object fails with the same
canceled error.
To avoid this, clear the error in this case and destroy any member
variables that may have been created before the creation was canceled.
This way, the initialization of the second proxy object will restart the
connection initialization and with probably succeed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Nicks and blurbs don't have any practical use for gio/gobject libraries.
Leaving tests untouched since this features is still used by other libraries.
Closes#2991
GDBus has always supported matching strings with arg0 matching
(`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH`). In D-Bus 1.5, support was added
to the spec for also matching object paths. This got forgotten about and
was never added to GDBus, meaning that
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH` won’t match against a signal arg0
of type `o`.
Fix that, and add a unit test.
To do so, we need to add a new `g_dbus_message_get_arg0_path()` API to
complement the existing `g_dbus_message_get_arg0()` API. The approach of
letting `g_dbus_message_get_arg0()` return an object-path *or* a string
would not work, as it’s also called in the implementation of
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_NAMESPACE`, which must only match
string-typed arg0 values and not object-path-typed ones.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3183
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The ref on the timeout source owned by `SendMessageData` was being
dropped just after attaching the source to the main context, leaving it
unowned in that struct. That meant the only ref on the source was held
by the `GMainContext` it was attached to.
This ref was dropped when returning `G_SOURCE_REMOVE` from
`send_message_with_reply_timeout_cb()`. Before that happens,
`send_message_data_deliver_error()` is called, which normally calls
`send_message_with_reply_cleanup()` and destroys the source.
However, if `send_message_data_deliver_error()` is called when the
message has already been delivered, calling
`send_message_with_reply_cleanup()` will be skipped. This leaves the
source pointer in `SendMessageData` dangling, which will cause problems
when `g_source_destroy()` is subsequently called on it.
I’m not sure if it’s possible in practice for this situation to occur,
but the code certainly does nothing to prevent it, and it’s easy enough
to avoid by keeping a strong ref on the source in `SendMessageData`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
It already implicitly held a strong ref on its `GTask` values, but
didn’t have a free function set so that they would be automatically
unreffed on removal from the map.
This meant that the functions handling removals from the map,
`on_worker_closed()` (via `cancel_method_on_close()`) and
`send_message_with_reply_cleanup()` had to call unref once more than
they would otherwise.
In `send_message_with_reply_cleanup()`, this behaviour depended on
whether it was called with `remove == TRUE`. If not, it was `(transfer
none)` not `(transfer full)`. This led to bugs in its callers.
For example, this led to a direct leak in `cancel_method_on_close()`, as
it needed to remove tasks from `map_method_serial_to_task`, but called
`send_message_with_reply_cleanup(remove = FALSE)` and erroneously didn’t
call unref an additional time.
Try and simplify it all by setting a `GDestroyNotify` on
`map_method_serial_to_task`’s values, and making the refcount handling
of `send_message_with_reply_cleanup()` not be conditional on its
arguments.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
Add a missing steal call in `schedule_method_call()`. This introduces no
functional changes, but documents the ownership transfer more clearly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2924
Otherwise it’s possible for it to hang around in the `GMainContext`
after the “send message” operation has finished. In the best case, this
will cause the `GTask` and `GDBusMessage` to not be freed when the
calling code expects. In the worst case, it could cause use-after-free
problems if it derefs allocations which have since been freed.
I have not seen either of these problems in practice, but it would be
best for the code to eliminate the risk of them altogether by explicitly
destroying the source when the operation is finished.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2925
This introduces no functional changes, but makes it a little clearer how
the ownership of these `GDBusMessage` instances works. The free function
is changed to `g_clear_object()` to avoid the possibility of somehow
using the messages after freeing them.
Basically just some drive-by docs improvements while trying to debug
issue #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This didn’t actually cause any observable bugs, since the structures of
`PropertyData` and `PropertyGetAllData` were equivalent for the members
which the free function touches.
Definitely should be fixed though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This appears to fix an intermittent failure seen when sending a D-Bus
message with either of a cancellable or a timeout set.
In particular, I can reliably reproduce it with:
```
meson test gdbus-test-codegen-min-required-2-64 --repeat 10000
```
It can be caught easily with asan when reproduced. Tracking down the
location of the refcount mismatch was a little tricky, but was
simplified by replacing a load of `g_object_ref (message)` calls with
`g_dbus_message_copy (message, NULL)` to switch `GDBusMessage` handling
to using copy semantics. This allowed asan to home in on where the
refcount mismatch was happening.
The problem was that `send_message_data_deliver_error()` takes ownership
of the `GTask` passed to it, but the
`send_message_with_replace_cancelled_idle_cb()` and
`send_message_with_reply_timeout_cb()` functions which were calling it,
were not passing in a strong reference as they should have.
Another approach to fixing this would have been to change the transfer
semantics of `send_message_data_deliver_error()` so it was `(transfer
none)` on its `GTask`. That would probably have resulted in cleaner
code, but would have been a lot harder to verify/review the fix, and
easier to inadvertently introduce new bugs.
The fact that the bug was only triggered by the cancellation and timeout
callbacks explains why it was intermittent: these code paths are
typically never hit, but the timeout path may sometimes be hit on a very
slow test run.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1264
We already set names on most sources, this
one was just forgotten. This lets us set
a static name, and prevents g_task_attach_source
from setting a non-static one.
The dominant implementations of the well-known session and system
message buses are the reference implementation from the dbus project
(dbus-daemon) and the sd-bus-based reimplementation dbus-broker, both
of which have correct implementations for EXTERNAL authentication with
an unspecified authorization identity.
This makes it reasonably safe to assume that the well-known message
buses can cope with the unspecified authorization identity, even if we
cannot make the same assumption for custom servers such as the ones
used in ibus and gvfs (which might have been started with an older
GLib version before upgrading GLib in-place).
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using a GDBus client in a non-trivial user namespace, the result of
geteuid() can differ from the uid in the namespace where the server is
running. This would result in connection attempts being rejected, because
the identity that the client claims to have does not match the identity
that the server derives from its credentials.
RFC 4422 allows us to send an empty authorization identity, which means we
want to authenticate as whatever identity the server can derive from our
out-of-band credentials. In particular, this resolves the authentication
failure when crossing between different Linux user namespaces.
Because D-Bus does not have a way to represent an empty initial response
as distinct from the absence of an initial response, we cannot use the
initial-response optimization (RFC 4422 §4.3.a) in this case, and must
fall back to waiting for the server to send a challenge.
Unfortunately, GDBus versions older than glib!2826 did not implement
the server side of this protocol correctly, and would respond to the
missing initial response in a way that breaks the SASL state machine
(expecting a response without sending a challenge), causing client and
server to deadlock with each waiting for the other to respond. Until
fixed versions of GDBus are widespread, we can't rely on having a server
that can cope with this, so gate it behind a flag, which can be set for
connections that are known to cross non-trivial namespace boundaries.
Originally inspired by
<1ed4723d38>,
and based on earlier work by Giuseppe Scrivano (in which the
cross-namespace behaviour was unconditional, rather than gated by a
flag).
Co-authored-by: Giuseppe Scrivano <giuseppe@scrivano.org>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
