]> git.baikalelectronics.ru Git - kernel.git/commit
eCryptfs: don't pass up plaintext names when using filename encryption
authorTyler Hicks <tyhicks@canonical.com>
Wed, 28 Mar 2018 23:41:52 +0000 (23:41 +0000)
committerTyler Hicks <tyhicks@canonical.com>
Mon, 16 Apr 2018 18:51:22 +0000 (18:51 +0000)
commitc562f3b5ae86f3abb4058124ca0946e959b5456b
tree541db393f7c69a9de74e647d5292774d8218989f
parent932630b6e8152aea3ba93de17e2b5d6eedec485f
eCryptfs: don't pass up plaintext names when using filename encryption

Both ecryptfs_filldir() and ecryptfs_readlink_lower() use
ecryptfs_decode_and_decrypt_filename() to translate lower filenames to
upper filenames. The function correctly passes up lower filenames,
unchanged, when filename encryption isn't in use. However, it was also
passing up lower filenames when the filename wasn't encrypted or
when decryption failed. Since 671a0229543e, eCryptfs refuses to lookup
lower plaintext names when filename encryption is enabled so this
resulted in a situation where userspace would see lower plaintext
filenames in calls to getdents(2) but then not be able to lookup those
filenames.

An example of this can be seen when enabling filename encryption on an
eCryptfs mount at the root directory of an Ext4 filesystem:

$ ls -1i /lower
12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE--
11 lost+found
$ ls -1i /upper
ls: cannot access '/upper/lost+found': No such file or directory
 ? lost+found
12 test

With this change, the lower lost+found dentry is ignored:

$ ls -1i /lower
12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE--
11 lost+found
$ ls -1i /upper
12 test

Additionally, some potentially noisy error/info messages in the related
code paths are turned into debug messages so that the logs can't be
easily filled.

Fixes: 671a0229543e ("ecryptfs_lookup(): try either only encrypted or plaintext name")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
fs/ecryptfs/crypto.c
fs/ecryptfs/file.c