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