Closed ulziibuyan closed 4 years ago
No. SquashFS neither supports ACLs nor xattrs with the system.*
prefix.
Many filesystems support POSIX ACLs by storing them in as xattrs (e.g. using the system.posix_acl_default
key in this case). This is not required by POSIX but it is easy to implement this way if a filesystem already has xattr support.
On the one hand, SquashFS does not have a concept of ACLs, on the other hand, it does have xattrs.
However, SquashFS uses an integer to encode the prefix of the xattr key. It currently supports 3 prefix ids: 0 for user.*
, 1 for trusted.*
and 2 for security.*
.
So even if it does not know about ACLs, it also cannot blindly encode xattr keys beginning with system.*
. Even if it could, that doesn't magically give it ACL support, because it doesn't implement the necessary kernel interface.
On a side note, there are TAR format extensions for storing ACLs that are unrelated to extended attributes. It's interesting that in your case the archiver just blindly stuffed the system.posix_acl_default
attributes into the archive.
Implementing ACL support requires an extension to the SquashFS format and the kernel implementation would have to be patched accordingly. This maybe also requires coordinating with squashfs-tools. To put it mildly: I expect the communication to be the difficult part here.
I've seen a patch set rotting on the mailing list that implements ACLs through the aforementioned xattr key and it acutally is dead simple.
However, it would be possible to implement ACLs more elegantly and space efficient, since SquashFS is read only. Furthermore, using plain UID/GID values completely sidesteps the SquashFS user/group ID table while using an internal encoding would in the end expose it to user space. A different key name should be used to not confuse broken programs that think ACLs are always encoded using that xattr key and try to parse it.
On the other hand, a more elegant approach that uses a dedicated table with an optimized internal encoding and references to the ID table would bring more drastic changes to the format with it. Especially also since inodes need to reference the entries in some way.
Closing this for now, as the format and the kernel both currently don't support ACLs.
Would this be supported?