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
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS
