Kai Lueke
23115eeaf1
When the extensions for the final system are already set up from the initrd we should avoid disrupting the boot process with the remount (which currently isn't atomic) and the daemon reload for systemd-confext and systemd-sysext. Similarly, when sysupdate ran and updated extensions it's best to avoid the remount and daemon reload if no changes are found. To do this, encode the current extension state in more detail than before where only the names of the extensions where encoded in the overlay mount. This can also be used to provide more details about the extension origin in "systemd-sysext status (--json=)". During the refresh add a check whether the old state matches the new state and in this case skip the refresh unless the user provides a flag to always refresh. Besides the extension name and the resolved path the best method for identification is the verity hash but that is not available for plain image files or directories. Therefore, also include data to check for file/directory replacements. The creation/modification times are not always real on reproducible images or extracted archive content. The file handle together with the unique mount ID is the next best identifier we can use when we have no verity hash. Fall back to an inode when we get no handle. With the creation/modification time and the path this should be good enough. Using a unique mount ID is important (with a fallback to the regular non-unique mount ID) instead of st_dev because st_dev gets reused too easily, e.g., by a loop device mount and the mount ID helps to catch this. For the mount ID to be valid it has to be resolved before we enter the new mount namespace. Thus, it gets provided by the image dissect logic and handed over to the sysext subprocess which runs in a new mount namespace. Luckily, we can rule out online modification of directories or image files because this is anyway not well supported with overlay mounts, so we don't do a file checksum nor do we recurse into a directory to look for the most recently touched files. But, as said, with the always-refresh flag one can force a reload.
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