Run the t_immutable test program for immutable/append-only files
and directories in an overlayfs upper directory.
This test is similar and was derived from generic/079, but
the original test is _notrun on overlay mount because FS_IOC_GETFLAGS
FS_IOC_SETFLAGS ioctls fail on overlay directory inodes.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Overlayfs should only filter out xattr starting with
"trusted.overlay.", not "trusted.overlay".
Setting xattrs like "trusted.overlay.xxx" is not allowed.
Setting xattrs like "trusted.overlayxxx" is allowed.
v4.8-rc1 introduced a regression that we can't set xattrs
like "trusted.overlayxxx". Kernel commit below fixed it
in v4.8:
fe2b75952347 ovl: Fix OVL_XATTR_PREFIX
This case tests both get/set of these 2 kinds of xattrs.
Pattern "trusted.overlay.xxx" should fail, however the
errno returned by set/get varies among kernel versions.
Pattern "trusted.overlayxxx" shold always work.
CC: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
tmpfs does not implement ->get_acl method, overlayfs
need to get its cached acls in permission check when
lower or upper fs is tmpfs.
CC: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
"work" directory in workdir should be cleaned up
and recreated while overlayfs mounting. Or overlayfs
will be mounted read-only.
CC: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
They should be cleaned while mounting overlayfs.
[eguan: remove uncorrect comments about getfacl filter]
CC: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Run 4 process pairs, each competing over copy up of 1K files
in 1 directory. One opponent touches all files in the directory
and the other truncates all files in the directory.
This test does NOT check for concurrent copy up support. It only
fails on unexpected errors of any of the touch/truncate operations.
The test full output should demonstrate the expected results -
for kernel with concurrent copy up support, truncate workers are
not delayed by touch workers. As a result, truncate workers will
finish their work much sooner than a test run without concurrent
copy up support.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Via unshare, copy up dir from lower dir then remove
them in another unshared namespace.
This would fail before v4.7 kernel with EPERM.
Kernel commit 3fe6e52f
ovl: override creds with the ones from the superblock mounter
fixed this issue, with this reproducer provided. Original
reproducer was written by commit author:
Antonio Murdaca <amurdaca@redhat.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a test which runs fsstress on the top and bottom overlayfs
directories simultaneously to find potential races that plagued
wrapfs derived file systems.
[eguan: add copyright info and fix minor code style issue]
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a new test to demonstrate a known issue with overlayfs:
- file A and B are hardlinked in lower
- modify A to trigger copy up
- file A is no longer a hardlink of file B
There is no fix for this issue at this time.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Tests 016 and 013 both test behavior of concurrent
file access during copy up (truncate+exec and read+write).
Associate those tests to the copyup group.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a new test to demonstrate a known issue with overlayfs:
- stat file A shows inode number X
- modify A to trigger copy up
- stat file A shows inode number Y != X
Also test if d_ino of readdir entries changes after copy up.
There is a POC patch by Miklos Szeredi that fixes this issue.
Not dealing with hardlinks here, because there is more to test
then stable inode number.
Hardlinks will get a test of their own.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a new test to demonstrates a known issue with overlayfs:
- process A opens file F for read
- process B writes new data to file F
- process A reads old data from file F
This issue is about to be fixed with a patch set by Miklos Szeredi.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Newly created files and dirs should inherit sgit bit from parent
dir, no matter the new files & dirs are created over whiteout or
not.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When copying up a directory with opaque xattr set, the xattr was
copied up as well, after a remount the opaque flag is honored so the
copied-up directory is treated as opaque, which causes files created
in the lowerdir to be hidden when using multiple lower directories.
This is fixed by "ovl: don't copy up opaqueness".
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test truncate running executable binaries from lower and upper dirs.
truncate(2) should return ETXTBSY, not other errno nor segfault
Commit 03bea6040932 ("ovl: get_write_access() in truncate") fixed
this issue.
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The upper dentry may become stale before we remove it from overlay,
e.g. file was removed from upperdir directly, which triggered
warning/oops in ovl_remove_and_whiteout().
Commit cfc9fde0b07c ("ovl: verify upper dentry in
ovl_remove_and_whiteout()") fixed this issue.
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test dump overlay private xattr on overlayfs with multiple lower
dirs. All the lower layers, except the lowest one, should honor
overlay private xattr "trusted.overlay", which means it should not
be visible to user.
Commit b581755b1c56 ("ovl: xattr filter fix") fixed this issue.
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test the removal of a dir which contains whiteout from lower dir,
which could crash the kernel.
The following kernel commit fixed this issue
84889d4 ovl: check dentry positiveness in ovl_cleanup_whiteouts()
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
overlayfs was leaking dentry on non-directories when using the
'default_permissions' mount option, which resulted in "BUG Dentry
still in use".
The following kernel commit fixed it:
ovl: fix dentry leak for default_permissions
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Create file/dir over whiteout by another user, uid/gid of the
file/dir should be current fsuid/fsgid, not the mounter's.
This upstream kernel patch fixed the issue
d0e13f5 ovl: fix uid/gid when creating over whiteout
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test getcwd() failure after unsuccessful rmdir, the getcwd() call
should return the correct path.
Upstream commit ce9113bbcbf4 ("ovl: fix getcwd() failure after
unsuccessful rmdir") fixed this issue.
Reviewed-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Amir Goldstein
Xiong Zhou
Theodore Ts'o
Eryu Guan