eCryptfs: don't pass fs-specific ioctl commands through
authorTyler Hicks <tyhicks@canonical.com>
Wed, 25 Feb 2015 01:28:10 +0000 (19:28 -0600)
committerTyler Hicks <tyhicks@canonical.com>
Tue, 3 Mar 2015 08:03:56 +0000 (02:03 -0600)
commit6d65261a09adaa374c05de807f73a144d783669e
treec9fceb28a3097d7885df1ae6b67af0bd154a4708
parent2a559a8bdeae853b6a8abb477c88875e1d4de591
eCryptfs: don't pass fs-specific ioctl commands through

eCryptfs can't be aware of what to expect when after passing an
arbitrary ioctl command through to the lower filesystem. The ioctl
command may trigger an action in the lower filesystem that is
incompatible with eCryptfs.

One specific example is when one attempts to use the Btrfs clone
ioctl command when the source file is in the Btrfs filesystem that
eCryptfs is mounted on top of and the destination fd is from a new file
created in the eCryptfs mount. The ioctl syscall incorrectly returns
success because the command is passed down to Btrfs which thinks that it
was able to do the clone operation. However, the result is an empty
eCryptfs file.

This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl
commands through and then copies up the inode metadata from the lower
inode to the eCryptfs inode to catch any changes made to the lower
inode's metadata. Those five ioctl commands are mostly common across all
filesystems but the whitelist may need to be further pruned in the
future.

https://bugzilla.kernel.org/show_bug.cgi?id=93691
https://launchpad.net/bugs/1305335

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: Rocko <rockorequin@hotmail.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: stable@vger.kernel.org # v2.6.36+: c43f7b8 eCryptfs: Handle ioctl calls with unlocked and compat functions
fs/ecryptfs/file.c