Since opening an encrypted regular file that is locked fails with ENOKEY, getting the encryption policy of such a file is not possible. As a result, 'fscrypt status' and 'fscrypt lock' fail on such files. Provide a better error message that tries to explain what is going on. Resolves https://github.com/google/fscrypt/issues/393
Split policyIoctl into setPolicyIoctl and getPolicyIoctl. Add a os.Sync() call to setPolicyIoctl. Policy ioctls are not necessary durable on return. For example, on ext4 (ref: fs/ext4/crypto.c: ext4_set_context) they are not. This may lead to a filesystem containing fscrypt metadata (in .fscrypt), but without the policy applied on an encrypted directory. Example: Snapshotting a mounted ext4 filesystem on Ceph RBD right after setting the policy. While subject to timing, with high probability the snapshot will not have the policy set. Calling fsync fixes this. Signed-off-by: Marcel Lauhoff <marcel.lauhoff@suse.com>
ErrBadOwners: Rename to ErrDirectoryNotOwned for clarity, move it from cmd/fscrypt/ to metadata/ where it better belongs, and improve the message. ErrEncrypted: Rename to ErrAlreadyEncrypted for clarity, and include the path. ErrNotEncrypted: Include the path. ErrBadEncryptionOptions: Include the path and bad options. ErrEncryptionNotSupported: ErrEncryptionNotEnabled: Don't wrap with "get encryption policy %s", in preparation for wrapping these with filesystem-level context instead. Also avoid mixing together the error handling for the "get policy" and "set policy" ioctls. Make it very clear how we're handling the errors from each ioctl.
Linux v5.4 and later supports v2 encryption policies. These have several advantages over v1 encryption policies: - Their encryption keys can be added/removed to/from the filesystem by non-root users, thus gaining the benefits of the filesystem keyring while also retaining support for non-root use. - They use a more standard, secure, and flexible key derivation function. Because of this, some future kernel-level fscrypt features will be implemented for v2 policies only. - They prevent a denial-of-service attack where a user could associate the wrong key with another user's encrypted files. Prepare the fscrypt tool to support v2 encryption policies by: - Adding a policy_version field to the EncryptionOptions, i.e. to the config file and to the policy metadata files. - Using the kernel-specified algorithm to compute the key descriptor for v2 policies. - Handling setting and getting v2 policies. Actually adding/removing the keys for v2 policies to/from the kernel is left for the next patch.
Use the new name for fscrypt constants and structures which have been given a new name. Also use the named constant for the DIRECT_KEY fscrypt policy flag. No change in behavior. This is just preparing for future work.
Add Adiantum support to the fscrypt userspace tool. Supported in the kernel since v5.0-rc1, Adiantum is a length-preserving encryption mode based primarily on XChaCha12. It is fast even on CPUs without AES instructions. Unlike XTS it is also a wide-block encryption mode. Adiantum is supported for both contents and filenames encryption. For Adiantum encryption policies, also make the fscrypt tool provide the new DIRECT_KEY flag, which further improves performance by requesting that all files be encrypted directly with the policy key. This takes advantage of Adiantum's support for long tweaks. See the kernel commit "fscrypt: add Adiantum support" (https://git.kernel.org/torvalds/c/8094c3ceb21ad938) for more details.
Running "go vet -shadow ./..." finds all places where a variable might be incorrectly or unnecessarily shadowed. This fixes some of them.
This commit changes all the internal import paths from `fscrypt/foo` to `github.com/google/fscrypt/foo` so that it can be built once we release externaly. The documentation in README.md is updated accordingly. Also, the README has a note noting that we do not make any guarantees about project stability before 1.0 (when it ships with Ubuntu). Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280