Daan De Meyer
7eb016d60b
The managed-namespace state lives only in the pinned BPF maps, which survive a plain restart. But an upgrade from a version whose map schema differs replaces those maps (they are pinned under a new directory), so they come up empty, and nothing repopulated them: every user namespace that was already running would silently lose its write restriction (and, for "self" allocations, its setgroups() denial) until it exited. Re-add every live registry entry to the BPF maps during manager_startup(), in the same pass that reaps the dead ones. userns_managed is reconstructed for all entries; the setgroups() denial is reconstructed from a flag now persisted in the registry, since it applies only to "self" allocations, which the map alone cannot tell apart. The update is idempotent when the pinned maps already carry the entries (the common restart case), and load-bearing after an upgrade that replaced them with empty ones. Ordering matters here: the programs are loaded but left unattached until the maps have been repopulated, and only then does the previous version's pin directory get removed, which is what detaches its programs. So the old policy keeps enforcing right up to the moment the new one takes over, and the new programs never run against a managed set that is still empty. Doing it the other way around would leave every pre-upgrade namespace failing open for the duration of the registry sweep, which is long enough for a client looping over create() to land a transient owned inode on a persistent file system. Entries written before that flag existed are exactly the ones the first such upgrade finds, so they get no answer from it. Recognize those by what the flag mirrors: a "self" allocation maps the UID of the caller rather than a transient range, i.e. it is the single UID entry whose start UID is its owner. This does not help a downgrade to a version without this change: such a version cannot clean up the newer pin directory it knows nothing about, so those programs stay attached until the next reboot clears the tmpfs-backed bpffs, with enforcement reverting to the older policy in the meantime.
System and Service Manager
Details
Most documentation is available on systemd's website.
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, and also repositories with packages built from the latest stable release