http://bugzilla.suse.com/show_bug.cgi?id=1089349 http://bugzilla.suse.com/show_bug.cgi?id=1089349#c6 Goldwyn Rodrigues <rgoldwyn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nfbrown@suse.com --- Comment #6 from Goldwyn Rodrigues <rgoldwyn@suse.com> --- (In reply to Fabian Vogt from comment #5)
(In reply to Goldwyn Rodrigues from comment #4)
On second thoughts, this is a security risk.
The handling for security_inode_copy_up_xattr is the same.
Not quite. The security_inode_copy_up_xattr copies the labels which are used by selinux to impose security restrictions. It just skips selinux (the only user) specific xattr.
If ACL is not be copied, the access permissions will change over an overlayfs mount.
ACLs are handled separately AFAICT. The only reason system.nfs4_acl exists as xattr is to provide userspace with the extended information NFSv4 ACLs provide over POSIX ACLs.
However, I'd say that this is a configuration issue by the system administrator - if the upper layer doesn't support a feature, it must not be relied on.
I don't think there's a better way to handle this, but I'd like to be proven otherwise.
There is already a discussion on this. https://www.spinics.net/lists/linux-nfs/msg61045.html Workaround is to use the exported FS without ACL. Adding Neil for inputs on NFS4 client. Neil: Can/Should empty nfs4_acls be suppressed? -- You are receiving this mail because: You are on the CC list for the bug.