We switched away from recvmsg_safe() in order to gracefully
handle MSG_CTRUNC. But MSG_TRUNC really shouldn't happen.
While at it, do not use RET_NERRNO with ssize_t.
We add some test cases for the previous commits: first (with Claude's
help) we exercise the message creation API internally by passing it
various combinations of incorrect fds with the might_be_truncated flag
set to true or false.
Then we try more of a "real world" test by lowering our fd limit and
sending ourselves a message via the bus and making sure that we
successfully receive a message that has had at least some of its fds
truncated.
In the event that we can't receive all of the fds from the message
(which can happen for a number of reasons including LSM denials or
hitting the fd limit of the process) the kernel will set the MSG_CTRUNC
flag. Through our use of recvmsg_safe() we've been treating this as a
fatal error, which will result in dropping the connection.
Let's dial that back a bit: we can receive the message, but when the
user attempts to access the missing fds via sd_bus_message_read_basic()
we can return the (existing) error code of -EBADMSG to indicate that the
fd is missing.
We can do this by using recvmsg() directly, and relaxing some of the
checks on message creation: when (and only when) we have received
MSG_CTRUNC we allow a smaller than expected (per the header) number of
fds to be present. The error check in sd_bus_message_read_basic() was
already there so we don't need to do anything about that.
This puts the receiver of the message into a difficult situation: you
can call sd_bus_message_read_basic() as often as you want but as long as
it keeps returning -EBADMSG it won't progress through the message and
you won't be able to close whatever container you're in. That means
that the user will probably need to abandon processing the message
anyway. So why not just drop the message up front? This approach is
more likely to yield a useful error message, which will be invaluable
for people trying to track down problems caused by LSM denials.
Fixes#34688
Our fuzzer CI recently got bumped to Ubuntu 24.04 with
glibc >= 2.35. Apparently msan is not happy with the new
epoll_pwait2(), hence explicitly mark the memory region
as initialized.
Fixes#40455
Alternative to #40463
This does not yet support directory images properly
as systemd itself does not support unpriv directory
images properly yet.
The user profiles are a copy of the system profiles but without
DynamicUser=yes (can't be used by user managers) and without
ProtectHome=yes (this masks /home which breaks StateDirectory= which
is lcoated inside /home)
The new "any" type was implemented by accident that it actually meant
"any but null" – unless marked as "any?" in which case it actually meant
truly any, including null. The spec change in
https://github.com/varlink/varlink.github.io/pull/43 otoh suggested that
"any" really means anything, and "any?" apparently too.
I think the implementation in code makes more sense than the spec change
however, hence let's add some checks/tests to ensure the behaviour of
the code is made explicitly and cared for.
I will prep a spec change to make the spec follow the code on this too.
Follow-up for: #39918
When a journal file is removed or corrupted, then the value `p`, which is
read from Object.data.entry_offset, may be zero.
Note, journal_file_move_to_object() checks the passed offset and return
-EBADMSG if it is invalid.
Fixes the issue reported at
https://github.com/systemd/systemd/pull/40372#issuecomment-3762907261.
Let's always use ret, ret_data and ret_size for output arguments.
size is better than length in this case because we're dealing with
arbitrary, possibly binary, data and not strings.
Let's introduce these for the following two reasons:
- Using them makes sure the parameter names match between declaration
and definition (if both use the corresponding macros).
- They make sure developers can't forget the _const_ and _pure_
attributes for the declarations.
This commit also includes some include sorting fixes
We drop the optimization for verify_sigchld as the
check differs based on the options passed and the
extra syscalls are certainly not going to matter
compared to the cost of forking a child process.
Fixes#40166
Let's move this from user-record.c into generic code and let's beef it
up a bit: allow parsing octal strings. This is particular relevant given
json_variant_new_stat() generates the mode in that format, and we
probably should be able to parse our own fields (even though we
currently don't do that for the data from json_variant_new_stat()).
Now that sd-event doesn't insist on blocking
SIGCHLD anymore when watching for process exit,
let's stop blocking SIGCHLD tree-wide where not
required anymore.
First, don't require blocking SIGCHLD for WEXITED. We watch for WEXITED
via pidfd instead of signalfd, so no need to insist on blocking SIGCHLD
anymore if we're only watching for WEXITED.
Second, do a proper check to see if the kernel autoreaping logic is
enabled. That has nothing to do with SIGCHLD being blocked for the current
thread or not. Instead, the kernel autoreaping logic is enabled either if
the disposition is set to SIG_IGN or if the SA_NOCLDWAIT flag is enabled.
When we send a batch of nfnl messages, but e.g. without sufficient
privilege, the kernel may only return an error message for
NFNL_MSG_BATCH_BEGIN and ignore all later messages.
So, we need to read the response for the NFNL_MSG_BATCH_BEGIN,
and if it is an error ignore the replies for the rest.
When we send a message with NLM_F_ACK, but if later we are not
interested in the reply and do not want to call sd_netlink_read(),
the reply will be stored in the rqueue forever.
Let's introduce a way to ignore received message without waiting reply.
When sd-event is attached to the sd-netlink object, use the timestamp of
the current event, otherwise call now().
This mostly change nothing. Preparation for later change.
… and also when it fails, in the few cases where this wasn't done already.
When I was debugging https://github.com/systemd/systemd/issues/39048, it
was quite confusing that we print copious information about D-Bus messages
and all other steps we're undertaking, but nothing about the sd-notify
messages which are much more important. Add some debug messages for the
cases where we didn't print anything. (The case where $NOTIFY_SOCKET is
not set in left unchanged. The variable is often left unset and we don't
need to spam logs in that trivial case.)
gcry_mpi_t is defined as "typedef struct gcry_mpi *gcry_mpi_t;".
When const is applied to this type, it resolves to
"struct gcry_mpi *const" instead of what we expect ("const struct gcry_mpi *").
So we end up with a const pointer to a mutable object instead of a mutable
pointer to a const object. Since the pointer passed to the function
is copied regardless, making it const has zero benefit.
You'd think we could instead stop using gcry_mpi_t and replace it with
"const struct gcry_mpi *", except that gcrypt leaked this mess into its
api, so it expects const pointers to mutable objects as well, which means
we can't take pointers to const objects as arguments, as we'd discard the qualifier
when calling a gcrypt function.
To avoid confusion, let's drop the const qualifiers from the gcry_mpi_t arguments.
Latest glibc uses _Generic to have strstr() and other functions return
const char* or char* based on whether the input is a const char* or a
char*. This causes build failures as we previously always expected a char*.
Let's fix the compilation failures and add our own macros similar to glibc's
to have string functions that return a mutable or const pointer depending on
the input.
Yu Watanabe
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Allison Karlitskaya
Lennart Poettering
Daan De Meyer
David Tardon
Luca Boccassi
Frantisek Sumsal