Stop generating and uploading coverage in CI
This avoids duplicate CI checks Signed-off-by: Joe Richey <joerichey@google.com>
This is currently broken, and we don't really use the findings. Signed-off-by: Joe Richey <joerichey@google.com>
pam_fscrypt: eliminate unnecessary options and improve documentation
Make some more corrections: - pam-config-framework isn't actually Ubuntu-specific but actually applies to Debian and any Debian derivative. - The pam-config-framework file is indeed installed by `make install`, just not into the correct location. - On Debian (and Debian derivatives), the PAM configuration isn't actually part of the 'fscrypt' package but rather 'libpam-fscrypt'. - Clarify where to add the pam_fscrypt.so session hook.
There are several mentions of pam_fscrypt handling unlocking directories. Make sure to mention locking alongside this.
All pam_fscrypt configuration guides that I'm aware of say to use the "lock_policies" option for the pam_fscrypt.so session hook. The Debian/Ubuntu pam-config-framework config file has it too. Make locking the default behavior, since this is what everyone wants. Existing configuration files that contain the "lock_policies" option will continue to work, but that option won't do anything anymore. (We could add an option "unlock_only" to restore the old default behavior, but it's not clear that it would be useful. So for simplicity, leave it out for now.)
Configuring whether pam_fscrypt drops caches or not isn't really something the user should have to do, and it's also irrelevant for v2 encryption policies (the default on newer systems). It's better to have pam_fscrypt automatically decide whether it needs to drop caches or not. Do this by making pam_fscrypt check whether any encryption policy keys are being removed from a user keyring (rather than from a filesystem keyring). If so, it drops caches; otherwise it doesn't. This supersedes the "drop_caches" option, which won't do anything anymore.
Services launched by systemd user sessions on Debian / Ubuntu systems are often not able to access the home directory, because there is no guarantee / requirement that pam_fscrypt is sequenced before pam_systemd. Although this pam-config mechanism is Debian-specific, the config file is provided here upstream and unmodified in Debian. Raising the priority here so that it's always ordered ahead of pam_systemd will solve issues such as https://github.com/google/fscrypt/issues/270, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964951 and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1889416. After a survey of pam-config files available in Debian bullseye, the value of 100 was chosen as it appears after most other plugins that could be involved in more explicit homedir configuration (eg pam_mount at 128) but before those which seem unlikely to work without a home directory (eg pam_ssh at 64).