Daan De Meyer
5fd5cd8718
tar_c() keeps a database of already seen inodes so it can emit hardlinks rather than storing the same content repeatedly. It prefers to keep that database on a tmpfs superblock of its own, which is created lazily on the first hardlinkable inode and which requires CAP_SYS_ADMIN in the caller's user namespace. Failing that it falls back to a temporary directory under /var/tmp/. In the tar child forked off by import_fork_tar_c() the tmpfs branch can never succeed: the child joins the user namespace, then drops all capabilities but CAP_DAC_OVERRIDE, and only afterwards runs tar_c(), by which point CAP_SYS_ADMIN is long gone. Every export therefore silently took the /var/tmp/ fallback. That fallback is a problem beyond being the slower path. The child runs with the transient UID range assigned to the user namespace, so the directory it creates is owned by a recyclable UID on a file system that outlives the namespace, which is exactly what the nsresourced BPF-LSM policy exists to prevent. With that policy in effect the mkdtemp() is refused and the export fails with EPERM. Create the database up front, in the window after the user namespace has been joined and before the capabilities are dropped, and pass the resulting fd into tar_c(). The database then lives on a superblock that dies together with the namespace, no persistent file system is touched, and the sandbox around tar is unchanged. tar_c() keeps its lazy fallback for the callers that do not pass an fd, i.e. systemd-dissect and the test, which do not run under a transient range. The fd is borrowed, not consumed. Signed-off-by: Daan De Meyer <daan@amutable.com>
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