1eb8a560a6
So far, at the one place we sent a PID over Varlink we did so as a simple numeric pid_t value. That's of course is racy, since classic PIDs are recycled too eagerly. Let's address that, by passing around JSON objects distantly resembling our PidRef structure. Note that this JSON object does *not* contain the pidfd, however, but just the pidfd inode number if known. I originally planned to include the pidfd in some direct form, but I figured that's not really the best idea, since we always need a side-channel of some form for that (i.e. AF_UNIX/SCM_RIGHTS), but we should be able to report about PIDs even without that. Moreover, while sending the pid number and pidfd id around should always be OK to do, it's a lot more problematic to always send a pidfd around, since that implies that fd passing is on and it is OK to install fds remotely in some IPC peers fd table. For example, when doing a wild dump of service manager service state we really shouldn't end up with a bunch of fds installed in our client's fd table. Hence, all in all I think it is cleaner to define a structure carrying pid number and pidfd inode id, wich is passed directly as JSON. And then optionally, in a separate field also pass around a pidfd where it makes sense. Note that sending around pidfds is not that beneficial anymore if we have the pidfd inode id, because we can always securely and reliably get a pidfd back from a pair of pid + inode id: first we do pidfd_open() on the pid, and then we check if it is really the right one by comparing .st_ino after fstat(). This logic is implemented gracefully: if for some reason pidfd/pidfd inode nrs are not available (too old kernel), we'll fall back to plain PID numbers. The dispatching logic knows two distinct levels of validation of the provided PID data: if SD_JSON_STRICT is specified we'll acquire a pidfd for the PID, thus verifying it currently exists and failing if it doesn't. If the flag is not set, well just store the provided info as-is, will try to acquire a pidfd for it, but not fail if we cannot. Both modes are important in different contexts. Also note that in addition to the pidfd inode nr we always store the current boot ID of the system in the JSON object, since only the combination of pidfd inode nr and boot ID of the system really is a world-wide unique reference to a process. When dispatching a JSON pid field we operate somewhat gracefully: we either support the triplet structure of pid, pid inode nr, boot id, or we accept a simple classic UNIX pid.
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