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

[Joerg Schilling]

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.

> bsdtar chokes on this because the Pax attributes are malformed.

Is this because you try to convert binary data from UTF-8?

> Quoting from ?IEEE Std 1003.1, 2013 Edition?
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
>
> >  An extended header shall consist of one or more records, each constructed 
> > as follows:
> > 
> > "%d %s=%s\n", <length>, <keyword>, <value>
> > 
> > The extended header records shall be encoded according to the ISO/IEC 
> > 10646-1:2000
> > standard UTF-8 encoding. The <length> field, <blank>, <equals-sign>, and 
> > <newline>
> > shown shall be limited to the portable character set, as encoded in UTF-8.
>
> Here?s a partial hexdump from the file in question.  The
> attribute in question starts with ?85? at the end of the first
> line:
>
> 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. 

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.

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.

For the same reason, it is most likely wrong to archive the extended attribute 
files SUNWattr_ro and SUNWattr_rw that appear e.g. in ZFS even though I expect 
the content to be portable across OpenSolaris, FeeeBSD and Linux. Note: the 
content of these files is created from libnvpair and thus could be called 
documented.

The next task for star is to implement NFSv4 ACL support for FreeBSD. From 
what I found in the net, there is currently no compatible NFSv4 ACL support on
Linux, so it currently seems to be a feature that only can be supported on 
OpenSolaris and FreeBSD.

The following task is extended attributes for the NFSv4 concept. I am 
interested in a discussion on how extended attribubes that follow the NFSv4 
concept should be best implemented in tar. This will from the current state be 
done using files on tar and this would prevent the problem with binary content.

Does anyone know whether there is another OS that implements the withdrawn 
POSIX draft for xattrs?

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily