Details
-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Lustre 2.4.1
-
lustre-2.4.0-19chaos (see http://github.com/chaos/lustre)
-
3
-
12867
Description
GNU cp -rp tries to store a default ACL on the destination if the source filesystem supports ACLs, even if the source file has no default ACL. If the destination is a Lustre filesystem with a ZFS MDT, an invalid or empty default ACL is applied, causing Lustre to bypass the umask in the destination directory. This shell snippet demonstrates the problem:
src=`mktemp -d XXXX` dest=`mktemp -u XXXX` getfattr -n system.posix_acl_default $src cp -rp $src $dest getfattr -n system.posix_acl_default $dest umask touch $dest/foo ls -l $dest/foo
Example output:
# oslic6 /p/lscratchv/bass6 > src=`mktemp -d XXXX` # oslic6 /p/lscratchv/bass6 > dest=`mktemp -u XXXX` # oslic6 /p/lscratchv/bass6 > getfattr -n system.posix_acl_default $src # file: g9Lo system.posix_acl_default # oslic6 /p/lscratchv/bass6 > cp -rp $src $dest # oslic6 /p/lscratchv/bass6 > getfattr -n system.posix_acl_default $dest # file: U0tY system.posix_acl_default=0sAgAAAA== # oslic6 /p/lscratchv/bass6 > umask 0077 # oslic6 /p/lscratchv/bass6 > touch $dest/foo # oslic6 /p/lscratchv/bass6 > ls -l $dest/foo -rw-rw-rw- 1 root root 0 Feb 27 14:20 U0tY/foo
Note the file foo has mode 0666 even though umask was 0077. Running this test on an ldiskfs filesystem shows that the invalid/empty ACL is discarded, so umask still works as expected.