Re: [Bug-tar] GNU tar generates malformed Pax attributes

[Pavel Raiskup]

On Monday, December 09, 2013 00:02:41 Joerg Schilling wrote:
> Tim Kientzle <address@hidden> 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