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
The very common case for this function is that during AUTH EXTERNAL,
it receives a Unix uid encoded as an ASCII decimal integer. There is
no need to look up such uids in the system's user database
(/etc/password or NSS) when the only information we are going to use
from the DBusUserInfo struct is the uid anyway. This avoids taking
the lock and performing a potentially time-consuming NSS lookup.
This changes behaviour in one corner case: if a privileged process has
used one of the set*uid family of functions to set its effective uid
to a numeric uid that does not exist in the system's user database,
we would previously fail. Now, we succeed anyway: it is true to say
in the DBusCredentials that the process has uid 12345, even if uid
12345 does not correspond to any named user.
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
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This means we can accept connections on the new socket. For now, we
don't process them and they get closed.
For the system bus (or root's session bus, where the difference is
harmless but makes automated testing easier), rely on system-wide
infrastructure to create /run/dbus/containers. The upstream dbus
distribution no longer contains integration glue for non-systemd boot
systems, but downstreams that maintain a non-systemd boot system and are
interested in the Containers interface should create /run/dbus/containers
during boot.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
For now, this is considered to be a privileged operation, because the
resource-limiting isn't wired up yet. It only contains the bare minimum
of API.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
These aren't *that* verbose, so it seems OK to print them all the time,
not just in the needlessly spammy verbose mode.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This function worked with a (string,position,length) triple, but it
turns out to only have one caller, which tells it to look at the
entire string anyway. It'll be easier to document if all the offsets
start from 0.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Commit 0c03b505 was meant to clear all the fds indexed by j in
[0, n_fds), which socket_disconnect() can't be allowed to close
(because on failure the caller remains responsible for closing them);
but instead it closed the one we failed to add to the main loop
(fd i), repeatedly.
Similarly, it was meant to invalidate all the watches indexed by j
in [i, n_fds) (the one we failed to add to the main loop and the ones
we didn't try to add to the main loop yet), which socket_disconnect()
can't be allowed to see (because it would fail to remove them from
the main loop and hit an assertion failure); but instead it invalidated
fd i, repeatedly.
These happen to be the same thing if you only have one fd, resulting
in the test-case passing on an IPv4-only system, but failing on a
system with both IPv4 and IPv6.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
dbus_realloc() doesn't guarantee to set errno (if it did, the
only reasonable thing it could set it to would be ENOMEM). In
particular, faking OOM conditions doesn't set it. This can cause an
assertion failure when OOM tests assert that the only error that can
validly occur is DBUS_ERROR_NO_MEMORY.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
If _dbus_noncefile_create() has failed and set error, it is incorrect
for us to set it again.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
If _dbus_server_new_for_socket() fails, it is the caller's
responsibility to close the fds. All other callers did this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
_dbus_server_finalize_base() asserts that the socket has been
disconnected, but in some OOM code paths we would call it without
officially disconnecting. Do so.
This means we need to be a bit more careful about what is
socket_disconnect()'s responsibility to clean up, what is
_dbus_server_new_for_socket()'s responsibility, and what is the caller's
responsibility.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
We assert that every watch is invalidated before it is freed, but
in some OOM code paths this didn't happen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
This is one of the few places that has test coverage for all the OOM
code paths. It was also one of the worst (most complicated)
error-unwinding locations, with labels failed_0 up to failed_4.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
This means we can finally use patterns like this:
DBusString buffer = _DBUS_STRING_INIT_INVALID;
dbus_bool_t ret = FALSE;
... some long setup ...
if (!_dbus_string_init (&buffer))
goto out;
... some long operation ...
ret = TRUE;
out:
... free things ...
_dbus_string_free (&buffer);
... free more things ...
return ret;
without having to have a separate boolean to track whether buffer has
been initialized.
One observable difference is that if s is a "const" (borrowed pointer)
string, _dbus_string_free (&s) now sets it to be invalid. Previously,
it would have kept its (borrowed pointer) contents, which seems like
a violation of least-astonishment.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
It's easier to implement a stack-allocated string that is valid to
free (but for no other purpose) if we consider all-bits-zero to be
invalid.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
These tests were disabled by commit 9c3d566, which rewrote the D-Bus
type system to be fully recursive, back in 2005. The message builder
was subsequently removed by commit 9d21554, also in early 2005.
It will probably take significant work to turn these files into
test-cases that use the current D-Bus type system and so can be run
this decade. Until that work is done, let's not ship them: we can
always fetch them from git history if we want them.
The single .message-raw file can still be read and has been retained,
although it hasn't actually tested the intended failure mode since
2005 due to changes to the D-Bus specification (it is a wire-protocol
version 0 message, and the recursive type system introduced in commit
9c3d566 changed the wire-protocol version to 1).
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103758
If we crash, we'll want to know what the most recent diagnostic was.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
The echo service frequently fails to connect to the bus when we are
testing OOM code paths, again causing a lot of noise in the log.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
In parts of the OOM testing, our logging produces multiple megabytes
of output. Let's not do that.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
stdout and stderr are close-on-exec and buffered, so we can't rely on
their buffers being empty. If we continue to execute application code
after forking (as opposed to immediately exec()ing), then the child
process might later flush the libc stdio buffers, resulting in
output that is printed by the parent also being printed by the child.
In particular, test-bus.log sometimes grows extremely large for
this reason, because this test repeatedly attempts to carry out
legacy activation.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
This is a little more self-documenting - it justifies why it's
acceptable to fail hard on out-of-memory conditions. _dbus_test_fatal()
isn't compiled unless we are compiling embedded tests, so compiling
with embedded tests disabled provides reasonable confidence that we
aren't using _dbus_test_fatal() inappropriately.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Unlike _dbus_assert_not_reached(), this new function takes a printf-style
format string, so we don't need to use a _dbus_warn() to explain why
the failure occurred (unless the failure message is multi-line).
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add an explanatory comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
This is still not how warnings and diagnostics should be done
(the advice should probably be included in the DBusError) but at least
this way it won't interfere with machine-readable output on stdout.
See also https://bugs.freedesktop.org/show_bug.cgi?id=103756
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Added a reference to #103756]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Printing to stdout would interfere with generating TAP syntax.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
If we combine the dbus_new0, populating the DBusString members and the
actual creation of the file, RAII-style, then we never need to worry
about a partially-initialized or uninitialized DBusNonceFile becoming
visible to a caller.
Similarly, if we combine deletion of the file, freeing of the
DBusString members, freeing the structure and clearing the pointer to
the structure, then we can never be in an inconsistent situation,
except during the actual implementation of _dbus_noncefile_delete().
Note that there are two implementations each of
_dbus_noncefile_create() and _dbus_noncefile_delete(). This is because
on Unix we must use a subdirectory of _dbus_get_tmpdir() (the nonce
filename is not created atomically, so that would not be safe), while
on Windows we use the directory directly (the Windows temp directory
is private to a user, so this is OK).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
This was always leaked, both on success and on error.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
We could free all of these without having ever successfully
initialized them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
If _dbus_string_init() fails, it doesn't guarantee that the string
is initialized to anything in particular. Worse, if
_dbus_string_init (&buffer) fails, p would never have been initialized
at all, due to the use of the short-circuiting || operator.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
