AgentD / squashfs-tools-ng

A new set of tools and libraries for working with SquashFS images
Other
194 stars 30 forks source link

ERROR: squashfs does not support xattr prefix of system.posix_acl_default #25

Closed ulziibuyan closed 4 years ago

ulziibuyan commented 4 years ago
% tar2sqfs --no-skip container.squashfs < container.tar
...
Packing backup/container/rootfs/var/log/journal
ERROR: squashfs does not support xattr prefix of system.posix_acl_default
%

Would this be supported?

AgentD commented 4 years ago

Short answer

No. SquashFS neither supports ACLs nor xattrs with the system.* prefix.

More detailed answer

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.

My thoughts on implementing ACL support so far

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.

AgentD commented 4 years ago

Closing this for now, as the format and the kernel both currently don't support ACLs.