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
Root can read all files, so this test fails when running as root. Skip it instead. Resolves https://github.com/google/fscrypt/issues/288
Introduce filesystem.ErrEncryptionNotEnabled and filesystem.ErrEncryptionNotSupported which include the Mount as context, and translate the corresponding metadata/ errors into them. Then make these errors show much better suggestions. Also replace lots of other filesystem/ errors with either custom types or with unnamed one-off errors that include more context. Fix backwards wrapping in lots of cases. Finally, don't include the mountpoint in places where it's not useful, like OS-level errors that already include the path.
ErrMissingPolicyMetadata: Include the mount, directory path, and metadata path. Also move the explanation into actions/ since it doesn't refer to any CLI command. ErrPolicyMetadataMismatch: Include a lot more information. Also start checking for consistency of the policy key descriptors, not just the encryption options. Add a test for this. ErrDifferentFilesystem: Include the mountpoints. ErrOnlyProtector: Clarify the message and include the protector descriptor. ErrAlreadyProtected: ErrNotProtected: Include the policy and protector descriptors. ErrAccessDeniedPossiblyV2: Make it slightly clearer what failed. Also move the explanation into actions/ since it doesn't refer to any CLI command.
Allow setting FSCRYPT_CONSISTENT_OUTPUT=1 in the environment to cause policies and protectors to sorted by last modification time. The CLI tests need this to make the output of 'fscrypt' ordered in a consistent way with regard to the operations performed.
Update the /proc/self/mountinfo parsing code to allow selecting a Mount with Subtree != "/", i.e. a Mount not of the full filesystem. This is needed to allow fscrypt to work in containers, where the root of the filesystem may not be mounted. See findMainMount() for details about the algorithm used. Resolves https://github.com/google/fscrypt/issues/211
If trying to unlock a v2-encrypted directory fails because the kernel lacks support for v2 policies, show a better error message. This can happen if someone downgrades their kernel or tries to access encrypted directories on removable storage from a computer with an older kernel. Detecting this case is difficult since all we have to go with is EACCES when opening the directory. Implement a heuristic where if get EACCES, we actually have read access to the directory, and the kernel doesn't support v2 policies, we show the improved error message. Before: # fscrypt unlock dir [ERROR] fscrypt unlock: open dir: permission denied After: # fscrypt unlock dir [ERROR] fscrypt unlock: open dir: permission denied This may be caused by the directory using a v2 encryption policy and the current kernel not supporting it. If indeed the case, then this directory can only be used on kernel v5.4 and later. You can create directories accessible on older kernels by changing policy_version to 1 in /etc/fscrypt.conf.
When adding a protector to a policy, don't unconditionally overwrite the protector link, because it may already exist. Instead, if it already exists and points to the mount, just use it. If it already exists and points to the wrong place, return an error. Also add a bool to the return value of AddLinkedProtector() so that callers can check whether the link was newly created or not.
canonicalizePath() is now only used by an error path in getMountFromLink(), which we can make use getDeviceName() instead.