linux-stable.git/fs/overlayfs, branch linux-4.1.y

ovl: filter trusted xattr for non-admin

2018-05-23T01:36:26+00:00

[ Upstream commit a082c6f680da298cf075886ff032f32ccb7c5e1a ]

Filesystems filter out extended attributes in the "trusted." domain for
unprivlieged callers.

Overlay calls underlying filesystem's method with elevated privs, so need
to do the filtering in overlayfs too.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin

ovl: fix failure to fsync lower dir

2018-03-04T15:28:22+00:00

[ Upstream commit d796e77f1dd541fe34481af2eee6454688d13982 ]

As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.

This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.

The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.

Reported-by: Raphael Hertzog 
Cc:  # v3.18
Signed-off-by: Amir Goldstein 
Tested-by: Raphaël Hertzog 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin

fs: Give dentry to inode_change_ok() instead of inode

2016-12-23T13:56:35+00:00

[ Upstream commit 31051c85b5e2aaaf6315f74c72a732673632a905 ]

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

References: CVE-2015-1350
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jan Kara 
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

ovl: fsync after copy-up

2016-11-26T03:57:03+00:00

[ Upstream commit 641089c1549d8d3df0b047b5de7e9a111362cdce ]

Make sure the copied up file hits the disk before renaming to the final
destination.  If this is not done then the copy-up may corrupt the data in
the file in case of a crash.

Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: fix workdir creation

2016-10-02T23:12:05+00:00

[ Upstream commit e1ff3dd1ae52cef5b5373c8cc4ad949c2c25a71c ]

Workdir creation fails in latest kernel.

Fix by allowing EOPNOTSUPP as a valid return value from
vfs_removexattr(XATTR_NAME_POSIX_ACL_*).  Upper filesystem may not support
ACL and still be perfectly able to support overlayfs.

Reported-by: Martin Ziegler 
Signed-off-by: Miklos Szeredi 
Fixes: c11b9fdd6a61 ("ovl: remove posix_acl_default from workdir")
Cc: 
Signed-off-by: Sasha Levin

ovl: listxattr: use strnlen()

2016-09-15T22:53:30+00:00

[ Upstream commit 7cb35119d067191ce9ebc380a599db0b03cbd9d9 ]

Be defensive about what underlying fs provides us in the returned xattr
list buffer.  If it's not properly null terminated, bail out with a warning
insead of BUG.

Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: remove posix_acl_default from workdir

2016-09-15T22:53:30+00:00

[ Upstream commit c11b9fdd6a612f376a5e886505f1c54c16d8c380 ]

Clear out posix acl xattrs on workdir and also reset the mode after
creation so that an inherited sgid bit is cleared.

Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: don't copy up opaqueness

2016-09-12T13:30:20+00:00

[ Upstream commit 0956254a2d5b9e2141385514553aeef694dfe3b5 ]

When a copy up of a directory occurs which has the opaque xattr set, the
xattr remains in the upper directory. The immediate behavior with overlayfs
is that the upper directory is not treated as opaque, however after a
remount the opaque flag is used and upper directory is treated as opaque.
This causes files created in the lower layer to be hidden when using
multiple lower directories.

Fix by not copying up the opaque flag.

To reproduce:

 ----8<---------8<---------8<---------8<---------8<---------8<----
mkdir -p l/d/s u v w mnt
mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt
rm -rf mnt/d/
mkdir -p mnt/d/n
umount mnt
mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
touch mnt/d/foo
umount mnt
mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
ls mnt/d
 ----8<---------8<---------8<---------8<---------8<---------8<----

output should be:  "foo  n"

Reported-by: Derek McGowan 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: verify upper dentry before unlink and rename

2016-08-20T03:08:45+00:00

[ Upstream commit 11f3710417d026ea2f4fcf362d866342c5274185 ]

Unlink and rename in overlayfs checked the upper dentry for staleness by
verifying upper->d_parent against upperdir.  However the dentry can go
stale also by being unhashed, for example.

Expand the verification to actually look up the name again (under parent
lock) and check if it matches the upper dentry.  This matches what the VFS
does before passing the dentry to filesytem's unlink/rename methods, which
excludes any inconsistency caused by overlayfs.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin

ovl: verify upper dentry in ovl_remove_and_whiteout()

2016-08-06T17:03:58+00:00

[ Upstream commit cfc9fde0b07c3b44b570057c5f93dda59dca1c94 ]

The upper dentry may become stale before we call ovl_lock_rename_workdir.
For example, someone could (mistakenly or maliciously) manually unlink(2)
it directly from upperdir.

To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir
and and check if it matches the upper dentry.

Essentially, it is the same problem and similar solution as in
commit 11f3710417d0 ("ovl: verify upper dentry before unlink and rename").

Signed-off-by: Maxim Patlasov 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin