On Monday, December 09, 2013 00:02:41 Joerg Schilling wrote: > Tim Kientzle <kient...@acm.org> wrote: > > > Pavel recently sent me an archive created with GNU tar > > that includes SCHILY.xattr extensions. > > I would guess that the problem is not SCHILY.xattr extensions in general but > a buggy implementation in gtar.
Sadly, I tend to disagree. The "SCHILY.xattr.attr" does not document encoding of binary data. That means, something like that results in creating binary data in pax Extended Header (on Linux): $ setfattr -n user.test -v 0x01020304 FILE $ star H=exustar -xattr -c -f test.star FILE (for that reason CC'ing back star mailing list) > > 00000340 73 65 72 2e 74 65 73 74 33 3d 61 68 6f 0a 38 35 > > |ser.test3=aho.85| > > 00000350 20 53 43 48 49 4c 59 2e 78 61 74 74 72 2e 73 79 | > > SCHILY.xattr.sy| > > 00000360 73 74 65 6d 2e 70 6f 73 69 78 5f 61 63 6c 5f 61 > > |stem.posix_acl_a| > > 00000370 63 63 65 73 73 3d 02 00 00 00 01 00 06 00 ff ff > > |ccess=..........| > > 00000380 ff ff 02 00 07 00 0f 00 00 00 04 00 06 00 ff ff > > |................| > > 00000390 ff ff 10 00 07 00 ff ff ff ff 20 00 04 00 ff ff |.......... > > .....| > > 000003a0 ff ff 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 > > |................| > > > > In particular, it appears that GNU tar is storing raw binary > > here. It is most definitely NOT valid UTF-8. > > > > I suppose I?ll have to rework libarchive?s pax parser to > > tolerate this. It would be nice if GNU tar could avoid > > such brokenness in the future. > > This is definitely a bug in gtar and I hope that not many archives exist > with this problem. According to that: At least archives coming from Red Hat distros (and possibly all distros having SELinux enabled) seem to produce bad archives (both with tar/star). The problem is that SELinux contexts are stored NULL terminated (otherwise completely printable), the 'getxattr()' correctly returns the string with trailing '\0' and that is stored then in tar header. I don't think that it is a big disaster and the conclusion is that we should stay backward compatible (which should not cost so much). > BTW: is this feature in use with gtar? I recently tried to compile gtar on > Solaris and it does not seem to support ACLs even though the Changelog claims > such support. Given the fact that star includes portable ACL support since > 2001 and Linux xattr support since 2003, I would guess that a typical user of > these features uses star instead of gtar. I am not able to test ACLs support on Solaris. But apart from the numeric ACL request [1] star/tar should be compatible in this regard. > Regarding the problem: > It should be obvious that it is an implementation detail that Linux > internally stores e.g. ACLs as "system xattrs" and that related data must > not appear in an archive. Star of course excludes such data from the > archive. Yes, but e.g. security.selinux is not excluded (yet?). ---- This should be fixed somehow in GNU tar/star. Maybe before that, we should approximate to standardize that pax xattr storage finally to reach some non capitalized keyword in pax header (Tim mentioned it some time ago). I mean linux/FreeBSD xattrs only, not the Solaris extended attributes as that should be in future standardized separately and should be discussed as Joerg said, not ACLs, not SELinux, ... Thanks, Pavel