Unlocked files not accessible by root

[fira959]

For several years I have occasionally noticed strange errors when I tried accessing my encrypted home files as root and I seem to have figured out how to reproduce this now:

Reproduction:

• UserA has a (home) directory encrypted with fscrypt
• UserA logs in, using their password for both authentication and fscrypt unlock (via pam)
• On a different tty, root logs in and tries to access the file /home/UserA/test/file, which fails with the error message "Required key not available". Running ls in that directory as root shows the random directory names expected from locked fscrypt directories.
• UserA now also goes into /home/UserA/test/ and runs ls, showing all files as normal.
• Back at the root shell, running ls now also shows all files as normal

Additional observations:

• If userA runs sudo -i to get a root shell and then accesses /home/UserA/test the files are always accessible. The issue only occurs when a shell is started directly as root.
• When a systemd services tries to access files in /home/userA/test/ the service also fails with "Required key not available" in the logs
• When I run a shellschript as root, started by pam_exec (as part of /etc/pam.d/system-login), it can access /home/userA/test/ without issues

The home directory in question is created by systemd-homed, but I noticed the issue before migrating to homed a few years back as well. Not sure if it is related.

Kernel version 6.9 fscrypt version v0.3.5

[ebiggers]

This is a known issue with v1 encryption policies which are obsolete but are still used by systemd-homed. This was all already fixed in this project (fscrypt) years ago by upgrading to v2, but we have no control over what systemd-homed does. Please direct your feedback to the systemd developers at https://github.com/systemd/systemd/issues/18280.

[fira959]

Thanks for the heads up.

Is there any known workaround to cache the keys for specific files that a service running as root may want to access?

[ebiggers]

IIRC, workarounds that people used to use for this issue include holding the files open in another process, or adding the keys to root's user keyring (may or may not work depending on the distro). I don't want to waste time thinking about this more, though, as I already fixed this 5 years ago. Please go bother the systemd people instead -- thanks :-)