Yu Watanabe
d20313d086
## Summary Closes #18280. `systemd-homed` currently writes fscrypt v1 policies, which bind the master key to the calling process's keyring. This 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 the file from a context that has the key first warms the page cache, but the underlying problem remains. v2 policies (Linux 5.4+) route the master key 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. This PR switches `systemd-homed` to v2 by default and keeps existing v1 homes working. ## Changes **`shared/crypto-util`**: Add `kdf_hkdf_derive` (HKDF, RFC 5869) wrapper around OpenSSL's `EVP_KDF` "HKDF", alongside the existing SSKDF/KBKDF helpers. **`homed/fscrypt`**: - Read the existing policy via `FS_IOC_GET_ENCRYPTION_POLICY_EX`, falling back to the legacy ioctl on pre-5.4 kernels. - `HomeSetup` now carries a full `struct fscrypt_key_specifier` instead of a bare 8-byte descriptor. Slot decryption derives either the v1 descriptor (double SHA-512) or the v2 identifier (HKDF-SHA512 with the kernel's info string) from the unwrapped volume key 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, reads the policy version, 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 when the kernel rejects v2. The on-disk slot xattr format is unchanged - the volume key is the same, only how it binds to the directory changes. There is no v1 -> v2 migration; existing v1 homes continue to unlock, rekey, and deactivate as before.
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