Not to be confused with _dbus_credentials_clear(), which does something
different (this is a little unfortunate, but the fact that they take
different types should clarify which is which).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
It can't actually matter in practice, because we never know the
Unix uid and Unix groups but not pid, and we never have a Windows SID
and also a Linux security label; but resetting join to FALSE can only
ever result in us outputting something like "foo=123bar=456" instead
of the intended form with a space in the middle.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
We have a lot of dbus_connection_get_foo() and
_dbus_transport_get_foo() that are actually rather redundant.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
This gives us feature parity with the Autotools build system for this
particular area, and in particular means a system dbus-daemon built
with cmake can expand its fd limit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
Startup ordering was changed in #92832 to ensure that SELinux audit
messages could be sent. As a side effect, the raising of file descriptor
limits was moved to after the dropping of root privileges, resulting in
the limit change always failing.
Move the raise_file_descriptor_limit() call to ensure that it is called
before dropping root privileges.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1529044
[smcv: Call raise_file_descriptor_limit() even if !context->user]
Reviewed-by: Simon McVittie <smcv@collabora.com>
In the bus daemon, don't pass through the container instance path:
if there's any value here at all, we want to be able to guarantee that
we sent it (in a later commit).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101899
We'll need this if we want to stamp optional header fields on the
message according to the preferences of the recipient(s).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101899
Based on code contributed by Manish Narang. This is not included in the
automated test suite, because it isn't reliable on heavily-loaded
automatic test infrastructure like Travis-CI.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the test to the CMake build system too, as requested]
[smcv: Convert into a manual test]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
DBusLoop isn't thread-safe, so we can't use it to test multi-threaded
situations.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
If one thread is blocking on a pending call, and another thread is
dispatching the connection, then we need them to agree on the value
of the completed flag by protecting all accesses with a lock. Reads
for this member seem to have the connection lock already, so it's
sufficient to make sure that the only write also happens under the
connection lock.
We already set the completed flag before calling the callback, so it
seems OK to stretch it to meaning that some thread has merely *taken
responsibility for* calling the callback.
The completed flag shares a bitfield with timeout_added, but that
flag is protected by the connection lock already.
Based on suggestions from Simon McVittie on
<https://bugs.freedesktop.org/show_bug.cgi?id=102839>.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
[smcv: Revert indentation changes; add commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
If a pending call is provided, _dbus_connection_do_iteration_unlocked
checks whether it has completed or has a reply ready as soon as it
acquires the I/O path. If that's the case, then the iteration
terminates without trying to carry out I/O, so that the pending call
can be dispatched immediately, without blocking until a timeout is
reached. This change is believed to be necessary, but not sufficient,
to resolve#102839.
Based on part of a patch from Michael Searle on
<https://bugs.freedesktop.org/show_bug.cgi?id=102839>.
Commit message added by Simon McVittie.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
Reviewed-by: Simon McVittie <smcv@collabora.com>
This file is the Unix counterpart of dbus-spawn-win.c, so it's less
confusing for it to have an indicative name.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
Otherwise the pre-commit hook won't let me rename it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
dbus-spawn.c and dbus-userdb* don't have obviously-Unix-specific names,
but are Unix-specific anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
Previously, USERID_HEX and USERNAME_HEX were both replaced by the hex
encoding of the numeric uid, something like 31303030 for "1000".
Now USERNAME_HEX is something like 736d6376 for "smcv". This is only
supported on Unix, but no authentication mechanisms use usernames on
Windows anyway.
This would require changing the tests that make use of USERNAME_HEX
if we had any, but we currently don't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
In the well-known system dbus-daemon, it's desirable to avoid looking
up non-numeric authorization identities in the user database, because
that could deadlock with NSS modules that directly or indirectly
require the system bus. Add a flag for whether the username will be
looked up in the userdb, and don't set that flag for EXTERNAL auth
(which is what we use on the system bus, and on the session bus
if not configured otherwise).
DBUS_COOKIE_SHA1 authentication is documented in terms of the
username (although in fact libdbus sends a numeric uid there too,
and GDBus only accepts a numeric uid) so continue to use the userdb
for that mechanism. DBUS_COOKIE_SHA1 needs to use the userdb on Unix
anyway, otherwise it won't find the user's home directory.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
While I'm changing its signature anyway, I might as well fix a
long-standing FIXME.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
