summaryrefslogtreecommitdiffstats
path: root/crypto/authenc.c
diff options
context:
space:
mode:
authorMiklos Szeredi <mszeredi@redhat.com>2017-09-05 12:53:12 +0200
committerMiklos Szeredi <mszeredi@redhat.com>2017-09-05 12:53:12 +0200
commit7c6893e3c9abf6a9676e060a1e35e5caca673d57 (patch)
treec14dda085d44e13a67c0d8f8d03113620f45bb7a /crypto/authenc.c
parentcd91304e7190b4c4802f8e413ab2214b233e0260 (diff)
downloadlinux-7c6893e3c9abf6a9676e060a1e35e5caca673d57.tar.gz
linux-7c6893e3c9abf6a9676e060a1e35e5caca673d57.tar.bz2
linux-7c6893e3c9abf6a9676e060a1e35e5caca673d57.zip
ovl: don't allow writing ioctl on lower layer
Problem with ioctl() is that it's a file operation, yet often used as an inode operation (i.e. modify the inode despite the file being opened for read-only). mnt_want_write_file() is used by filesystems in such cases to get write access on an arbitrary open file. Since overlayfs lets filesystems do all file operations, including ioctl, this can lead to mnt_want_write_file() returning OK for a lower file and modification of that lower file. This patch prevents modification by checking if the file is from an overlayfs lower layer and returning EPERM in that case. Need to introduce a mnt_want_write_file_path() variant that still does the old thing for inode operations that can do the copy up + modification correctly in such cases (fchown, fsetxattr, fremovexattr). This does not address the correctness of such ioctls on overlayfs (the correct way would be to copy up and attempt to perform ioctl on upper file). In theory this could be a regression. We very much hope that nobody is relying on such a hack in any sane setup. While this patch meddles in VFS code, it has no effect on non-overlayfs filesystems. Reported-by: "zhangyi (F)" <yi.zhang@huawei.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'crypto/authenc.c')
0 files changed, 0 insertions, 0 deletions