c7bf079bbc
This new helper is not used yet, but it's useful for apply UID/GID shifts so that the underlying home dir can use an arbitrary UID (for example "nobody") and we'll still make it appear as owned by the target UID. This operates roughly like this: 1. The relevant underlying UID is mapped to the target UID 2. Everything in the homed UID range except for the target UID is left unmapped (and thus will appear as "nobody") 3. Everything in the 16bit UID range outside of the homed UID range/target UID/nobody user is mapped to itself 4. Everything else is left unmapped (in particular everything outside of the 16 bit range). Why do it like this? The 2nd rule done to ensure that any files from homed's managed UID range that do not match the user's own UID will be shown as "unmapped" basically. Of course, IRL this should never happen, except if people managed to manipulate the underlying fs directly. The 3rd rule is to allow that if devs untar an OS image it more or less just works as before: 16bit UIDs outside of the homed range will be mapped onto themselves: you can untar things and tar it back up and things will just work.
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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.