summaryrefslogtreecommitdiff
path: root/fs/crypto/policy.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2020-05-12 16:32:49 -0700
committerEric Biggers <ebiggers@google.com>2020-05-15 13:51:45 -0700
commitcdeb21da1783afe26a827eb62d61084f93720be9 (patch)
treec03d2f3d6149aadf5dc76bbf866ed0e31d720b72 /fs/crypto/policy.c
parent8b85996095049a2216c0a6b582330ec75913243c (diff)
fscrypt: add fscrypt_add_test_dummy_key()
Currently, the test_dummy_encryption mount option (which is used for encryption I/O testing with xfstests) uses v1 encryption policies, and it relies on userspace inserting a test key into the session keyring. We need test_dummy_encryption to support v2 encryption policies too. Requiring userspace to add the test key doesn't work well with v2 policies, since v2 policies only support the filesystem keyring (not the session keyring), and keys in the filesystem keyring are lost when the filesystem is unmounted. Hooking all test code that unmounts and re-mounts the filesystem would be difficult. Instead, let's make the filesystem automatically add the test key to its keyring when test_dummy_encryption is enabled. That puts the responsibility for choosing the test key on the kernel. We could just hard-code a key. But out of paranoia, let's first try using a per-boot random key, to prevent this code from being misused. A per-boot key will work as long as no one expects dummy-encrypted files to remain accessible after a reboot. (gce-xfstests doesn't.) Therefore, this patch adds a function fscrypt_add_test_dummy_key() which implements the above. The next patch will use it. Link: https://lore.kernel.org/r/20200512233251.118314-3-ebiggers@kernel.org Reviewed-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to 'fs/crypto/policy.c')
0 files changed, 0 insertions, 0 deletions