Reference in a new issue

Blame

Copy permalink

Reference in a new issue

Copy permalink

Eric Biggers d259b68537 fscrypt: fix renaming and linking special files ... commit 42d97eb0ad upstream. Attempting to link a device node, named pipe, or socket file into an encrypted directory through rename(2) or link(2) always failed with EPERM. This happened because fscrypt_has_permitted_context() saw that the file was unencrypted and forbid creating the link. This behavior was unexpected because such files are never encrypted; only regular files, directories, and symlinks can be encrypted. To fix this, make fscrypt_has_permitted_context() always return true on special files. This will be covered by a test in my encryption xfstests patchset. Fixes: 9bd8212f98 ("ext4 crypto: add encryption policy and password salt support") Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>		History 2017-01-12 11:39:06 +01:00
..
crypto.c	fscrypto: make XTS tweak initialization endian-independent	2016-10-12 23:30:16 -04:00
fname.c	fscrypto: don't use on-stack buffer for filename encryption	2016-11-19 20:56:06 -05:00
Kconfig	fs crypto: move per-file encryption from f2fs tree to fs/crypto	2016-03-17 21:19:33 -07:00
keyinfo.c	fscrypto: don't use on-stack buffer for key derivation	2016-11-19 20:56:13 -05:00
Makefile	fs crypto: move per-file encryption from f2fs tree to fs/crypto	2016-03-17 21:19:33 -07:00
policy.c	fscrypt: fix renaming and linking special files	2017-01-12 11:39:06 +01:00