Forbid 'fscrypt setup' on filesystems that aren't expected to support encryption (other than the root filesystem), and skip looking for fscrypt metadata directories on such filesystems. This has two benefits. First, it avoids the printing of annoying warnings like: pam_fscrypt[75038]: stat /run/user/0/.fscrypt: permission denied pam_fscrypt[75038]: stat /run/user/0/.fscrypt/policies: permission denied pam_fscrypt[75038]: stat /run/user/0/.fscrypt/protectors: permission denied pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt: invalid argument pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt/policies: invalid argument pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt/protectors: invalid argument pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt: permission denied pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt/policies: permission denied pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt/protectors: permission denied Second, it avoids long delays or side effects on some filesystems. To do this, introduce an allowlist of filesystem types that fscrypt will recognize. I wanted to avoid doing this, since this list will need to be updated in the future, but I don't see a better solution.
When the root user creates a login protector for a non-root user, make sure to chown() the protector file to make it owned by the user. Without this, the protector cannot be updated by the user, which causes it to get out of sync if the user changes their login passphrase. Fixes https://github.com/google/fscrypt/issues/319
Fixes #123
As per the feedback at https://github.com/google/fscrypt/issues/115 where users didn't understand that the recovery passphrase is important, restore the original behavior where recovery passphrase generation happens automatically without a prompt. This applies to the case where 'fscrypt encrypt' is using a login protector on a non-root filesystem. However, leave the --no-recovery option so that the recovery passphrase can still be disabled if the user really wants to. Also, clarify the information provided about the recovery passphrase. Update https://github.com/google/fscrypt/issues/115
These confuse the latest version of shellcheck into thinking that functions which take no arguments actually take arguments, which triggers a bunch of warnings like "Use func "$@" if function's $1 should mean script's $1", which causes 'make lint' to fail. These checks aren't too useful, so just remove them.
Otherwise the cli tests fail when executed from GitHub Actions.
Apparently, on some distros 'su' doesn't preserve $PATH. So, manually export it in the command. Also, ensure that the shell stays as bash. This is needed for some of the CLI tests to pass in Travis CI.
When 'fscrypt status DIR' detects that a v1-encrypted directory is still usable but its key seems to be absent, it shows the status as "Unlocked: Partially (incompletely locked)". But actually it can also be the case that the directory is unlocked by another user. Adjust the status message accordingly. This commit also fixes cli-tests/t_v1_policy.
The test user's user keyring is still linked into root's user keyring at the end of the test. This is making the test flaky, as there is a failure that only occurs the first time it is run. Fix the test to restore the initial state. This makes it consistently fail (to be fixed by the next commit).