mv and posix ACLs

[Stephen Smalley]

On Tue, 2005-08-23 at 23:49 +1000, Russell Coker wrote:
> getxattr("/mnt/nfs/test", "system.posix_acl_access", 0xbfc96c20, 132) = -1 
> EOPNOTSUPP (Operation not supported)
> setxattr("./test", "system.posix_acl_access", 
> "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff 
> \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not 
> supported)
> 
> Stracing an mv operation shows that the above is performed.  Reading 
> coreutils-acl.patch from the coreutils SRPM indicates that the code in acl.c 
> is creating a posix ACL that matches the Unix permissions and trying to apply 
> it.
> 
> Why does it do this?  What is the point of having a POSIX ACL containing the 
> same data as the Unix permissions, it seems that when POSIX ACLs are enabled 
> in the destination file-system it will just waste disk space and CPU time by 
> needlessly duplicating data, and when POSIX ACLs are disabled (the default 
> configuration) it will just waste a small amount of CPU time on the mv 
> operation in trying to set something that can never be set.
> 
> This seems like a bug to me, but someone has obviously gone to quite a bit of 
> effort to make it do that so there is presumably some reason.  What is the 
> reason for desiring this functionality and does it really outweigh the 
> problems?

You might want to ask on the acl-devel list to be certain, but consider:
- In the absence of an explicit setting of the ACL on an ACL-enabled
filesystem, can the new file end up with an ACL based on the parent
directory's default ACL that yields a different protection than the
original file, as ACLs take precedence over file modes when present?
- It appears that the kernel performs a check when setting an ACL to see
whether it can be directly represented via a file mode, and if so,
stores it as a mode instead of an explicit ACL.   This avoids the issue
of wasting space at least.

-- 
Stephen Smalley
National Security Agency