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

[Joerg Schilling]

"Linda A. Walsh" <address@hidden> wrote:

> >> 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. 
> ----
>       I'm not sure it is a bug, but I'm sure only a POSIX lawyer could
> really say one way or another...;-)
>
> > 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.
> ----
> Not me.  star dumps core on my system.  Has for the past 4 releases
> of SUSE Linux (13.1, 12.3, 12.2, 12.1).  Last worked ~ 11.3 or so.

This is of course wrong. Nobody did ever report such a problem and even _you_ 
did not send a bug-report after I asked you to do so. It is obvous that we may 
savely assume that there is no such bug.


> > 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.
> ----
>
>       We are talking about dumping Xattrs, not ACLs.  It would be a bug
> to convert the file system Xattrs into some ACL-interpretation.  That
> interpretation depends on the OS, and is not part of the POSIX standard.
>
>       I.e. Linux should store exactly the Xattrs that are there -- not some
> pseudo ACL interpretation -- as that may be wrong.  If star is not storing the
> Xattrs as listed, I don't see how that would be correct.

It seems that you are missinterpreting things.

Let me repeat the important part: It is an implementation detail that you may 
see Linux ACLs as Linux xattrs. It is thus a bug to archive Linux ACLs as Linux 
xattrs, because there is a portable way to archive the ACLs that is used by 
star.


> > 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.
> ---
>       Xattrs are NOT portable between OS's.   Sun's ACL's are not portable
> to other OS's -- not Linux, and not Windows.  To try to convert them to some
> portable format would be very bad, since they don't map 1:1 and anything
> that isn't exactly the same would be a security flaw.

Wrong again!

The ACL draft that has been withdrawn in 1997 was a draft written after the 
Solaris ACL implementation from 1993.

If you have a filesystem with these outdated ACLs, you may move the files 
including the related ACLs between Solaris, UnixWare, *BSD, Linux, IRIX and AIX
using star. You don't miss any property if you do so. This will however not 
work if you are using gtar, so far I have been unable to compile gtar with ACL 
support enabled.

You may even unpack a star archive with the outdated ACLs on Solaris to a 
modern filesystem (ZFS) where those ACLs will be auto converted the the current 
ACL standard.

BTW: Extended attribute files from Solaris are a super set of what you get on 
Mac OS X and Win-DOS. So at least the storage is universal.

And in addition: As Solaris comes with an in kernel CIFS server, the current 
standard ACLs on Solaris are more than portable between Solaris and Win-DOS, 
you may share the same files on Solaris and Win-DOS using identical ACLs. The
fact that Linux is not compatible in this area seems to be a Linux specific 
problem. 

> > 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.
> ----
>       Because SunOS didn't follow the only "standards" [sic] that were
> in existence at the time (the withdrawn POSIX standard).  NOTE: it was
> withdrawn due to a lack of "quorum".   They some number of signatures (say
> 100 or 50) to ratify it as a standard.  By the time the document was finished,
> most of the members that had started out had dropped out (unix companies were
> going under around that time).

The companies that created the draft did stop their work on the withdrawn 
standard because the customers did not like to have this kind of ACLs. This is 
why the NFSv4 standard was set up in year 2000 including a bitwise copy of the 
NT-FS ACL system. 

> > Does anyone know whether there is another OS that implements the withdrawn 
> > POSIX draft for xattrs?
> ----
>       IRIX from sgi.

I tell you a secret: IRIX is dead since more than 7 years.


>
> ---- Uninteresting core dump of star-1.5final-61.1.2.x86_64 from SuSE 13.1 
> follows:
>
> *** buffer overflow detected ***: star terminated
> ======= Backtrace: =========
> /lib64/libc.so.6[0x300207410f]
> /lib64/libc.so.6(__fortify_fail+0x37)[0x30020f8657]
> /lib64/libc.so.6[0x30020f6800]
> star[0x427035]
> star[0x419037]

This is a star version that is 6 years old, so nobody currently cares about it 
anymore and the fact that you did never send any information that would allow 
to debug a potential reason makes it obvious that you do not have a problem, 
but rather like to grump without reason.

If you however are able to repeat a problem using a recent star version 
(1.5.3a01 or later) _and_ you send a stacktrace that includes the fault address 
and opcode, so debugging could be done, you are of course welcome.

As nobody did send a related bug report against star, there is little 
probability that you are able to repeat your so called problem using recent 
software.

If the problem you are talking about did ever exist it has been fixed long ago.

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