|
From: Nikolaus R. <Nik...@ra...> - 2013-01-17 05:15:52
|
Hello,
Some programs, like cp -a, seem to rely on the file system to
automagically convert the representable part of ACLs to permission bits.
For example, if a file "src" with mode 664 is copied using "cp -a src
dst", then cp creates the destination file with
open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
and then executes
fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
on the target. If this fails, it falls back on
fchmod(4, 0100664)
Now, on my low-level FUSE file system with xattr support, this results
with the destination file having the wrong permission bits (600), but
the correct ACL (664).
Doing the same thing on ext4, both ACL and permission bits are set
correctly to 664, even though cp never issued an fchmod call.
Is the file system supposed to apply ACL updates to permission bits as
well? If so, shouldn't this really be done in the kernel, or at least by
FUSE? Otherwise every FUSE file system would be required to implement
its own ACL parser and ACL-to-permission-bit converter.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
|