e64ccd2242
In68511cebe5the ability to pass the coredump's mount namespace fd from the coredump patter handler was added to systemd-coredump. For this the protocol was augmented, in attempt to provide both forward and backward compatibility. The protocol as of v256: one or more datagrams with journal log fields about the coredump are sent via an SOCK_SEQPACKET connection. It is finished with a zero length datagram which carries the coredump fd (this last datagram is called "sentinel" sometimes). The protocol after68511cebe5is extended so that after the sentinal a 2nd sentinel is sent, with a pair of fds: the coredump fd *again* and a mount fd (acquired via open_tree()) of the container's mount tree. It's a bit ugly to send the coredump fd a 2nd time, but what's more important the implementation didn't work: since on SOCK_SEQPACKET a zero sized datagram cannot be distinguished from EOF (which is a Linux API design mistake), an early EOF would be misunderstood as a zero size datagram lacking any fd, which resulted in protocol termination. Moreover, I think if we touch the protocol we should make the move to pidfs at the same time. All of the above is what this protocol rework addresses. 1. A pidfd is now sent as well 2. The protocol is now payload, followed by the coredump fd datagram (as before). But now followed by a second empty datagram with a pidfd, and a third empty datagram with the mount tree fd. Of this the latter two or last are optional. Thus, it's now a stream of payload datagrams with one, two or three fd-laden datagrams as sentinel. If we read the 2nd or 3rd sentinel without an attached fd we assume this is actually an EOF (whether it actually is one or not doesn't matter here). This should provide nice up and down compatibility. 3. The mount_tree_fd is moved into the Context object. The pidfd is placed there too, as a PidRef. Thus the data we pass around is now the coredump fd plus the context, which is simpler and makes a lot more semantical sense I think. 4. The "first" boolean is replaced by an explicit state engine enum Fixes: https://github.com/systemd/systemd/issues/34130
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