Ananth Bhaskararaman
571253fdbe
fscrypt v1 policies bind master keys to the calling process's keyring, which means files in a homed-managed directory aren't readable when accessed through a container bind mount, a different mount namespace, or by any process other than the one that first unlocked the home. Reading a file from outside such a context first warms the buffer cache and papers over the symptom (#18280), but the underlying problem (the key not flowing across keyrings) remains. v2 policies (Linux 5.4+) route master keys through the filesystem keyring via FS_IOC_ADD_ENCRYPTION_KEY / FS_IOC_REMOVE_ENCRYPTION_KEY, so the key is visible to every process accessing the filesystem. Switch homed to v2: - Read the existing policy via FS_IOC_GET_ENCRYPTION_POLICY_EX, which reports both v1 and v2 policies. The ioctl is available since Linux 5.4, i.e. on every kernel we support (our baseline is 5.10), so no fallback to the v1-only FS_IOC_GET_ENCRYPTION_POLICY is needed. - Drive slot matching off a full fscrypt_key_specifier (HomeSetup now carries that instead of a bare 8-byte descriptor). Slot decryption derives either the v1 descriptor (SHA-512 double hash) or the v2 identifier (HKDF-SHA512 with the kernel's info string), and compares against the policy. - Install the master key the right way per version: add_key("logon", ...) to thread+user keyrings for v1, FS_IOC_ADD_ENCRYPTION_KEY for v2. - home_flush_keyring_fscrypt opens the image directory, looks up the policy, and either calls FS_IOC_REMOVE_ENCRYPTION_KEY (v2) or walks the user keyring (v1). - New homes default to v2; fall back to v1 only if the kernel rejects FS_IOC_ADD_ENCRYPTION_KEY with ENOTTY/EOPNOTSUPP. The v2 create path derives the identifier locally first, passes it to ADD_KEY as expected_identifier, and cleans up via REMOVE_KEY if SET_POLICY then fails, so the v1 fallback never sees a stranded key. Existing v1 homes continue to unlock, rekey, and deactivate as before. - A v2 master key installed to work on an inactive home is always removed again unless that home ends up activated. v2 keys persist in the filesystem keyring until removed explicitly (v1 keys instead died with the homework process' keyring), so a key left behind would leave a home nobody activated readable until the next deactivation or reboot. home_setup_fscrypt() and home_create_fscrypt() therefore arm a rollback right after installing the key; the activation path disarms it once the mount is in place (the live home owns the key), while every other path -- create, and passwd/update/resize of an inactive home, plus all error paths -- rolls it back via home_setup_done(). Activation reinstalls the key. The v1 and v2 on-disk policy formats differ (v1: 8-byte descriptor; v2: 16-byte identifier) and fscrypt has no in-place upgrade path, so a v1 home is always unlocked via the v1 code path and a v2 home is always unlocked via the v2 code path, regardless of kernel version. Slot xattr format is unchanged: the master key is the same, only how it binds to the directory changes. Fixes #18280. Ananth Bhaskararaman antsub@gmail.com
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, and also repositories with packages built from the latest stable release