summaryrefslogtreecommitdiff
path: root/fs/ext4/ioctl.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2019-08-05 05:35:48 +0300
committerEric Biggers <ebiggers@google.com>2019-08-13 05:18:50 +0300
commit5ab7189a31bad40e4b44020cae6e56c8074721a1 (patch)
treed9cea4d978ce732bd9e97ded7782ebb2ec600829 /fs/ext4/ioctl.c
parent78a1b96bcf7a0721c7852bb1475218c3cbef884a (diff)
downloadlinux-5ab7189a31bad40e4b44020cae6e56c8074721a1.tar.xz
fscrypt: require that key be added when setting a v2 encryption policy
By looking up the master keys in a filesystem-level keyring rather than in the calling processes' key hierarchy, it becomes possible for a user to set an encryption policy which refers to some key they don't actually know, then encrypt their files using that key. Cryptographically this isn't much of a problem, but the semantics of this would be a bit weird. Thus, enforce that a v2 encryption policy can only be set if the user has previously added the key, or has capable(CAP_FOWNER). We tolerate that this problem will continue to exist for v1 encryption policies, however; there is no way around that. Reviewed-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to 'fs/ext4/ioctl.c')
0 files changed, 0 insertions, 0 deletions