Closed josch closed 3 years ago
Hi,
the issue here is a little bit more fundamental actually: SquashFS itself currently does not support ACLs (and also does not support the system
prefix for Xattrs). This would require a kernel side patch as well and could entail a minor design change in SquashFS if implemented cleanly (i.e. in a non-hacky way).
A key part of the issue here is also that ACLs and Xattrs are completely independent concepts. Some filesystems choose to store ACLs in special Xattr keys for simplicity.
In your case, the GNU tar program snorts up the Xattrs that the underlying filesystem uses for that. Technically the "correct" thing to do here actually is to strip those Xattrs out and use the appropriate tar extension for storing the ACLs properly, but even then tar2sqfs
currently cannot encode them.
I discussed this also in issue #25
If you pack the filesystem with mksquashfs
, you still have the same issue, it is just ignored silently.
Thanks a lot for the explanation and the pointer to issue #25 -- I now have something to point people to when they complain about this. I guess this issue can be closed for similar reasons as you already listed in #25.
Hi,
GNU tar supports the
user
,trusted
,security
andsystem
extended attribute namespaces. It seems tar2sqfs supports only the first three but notsystem
. This used to be fine for a squashfs of Debian 10 buster but is not anymore sufficient for the upcoming Debian 11 bullseye release which also includes the directory./var/log/journal/
with xattrs from thesystem.*
namespace:So for now we work around this by passing
--xattrs-exclude=system.*
when creating tarballs before passing them to tar2sqfs but it would be nice if in the future, tar2sqfs could somehow also support the system namespace in addition to the other three it already supports. Then maybe with Debian 12 bookworm we can pack Debian system images with tar2sqfs again without loss of information.Thanks!