Re: [Acl-devel] [Bug-tar] gtar's ACL support is still unusable

[Joerg Schilling]

Pavel Raiskup <address@hidden> wrote:

> Thanks for the report! +cc acl-devel
>
> On Thursday, March 14, 2019 2:51:10 PM CET Joerg Schilling wrote:
> > Trying to unpack the reference archives for the POSIX ACL proposal from
> > 1993 that was withdrawn in 1997 results in something like:
> > 
> > /tmp/tar-1.31/src/tar --acls -xpf acl-test3.tar.gz     
> > /tmp/tar-1.31/src/tar: default/dir2: Warnung: Funktion acl_from_text 
> > fehlgeschlagen
> > /tmp/tar-1.31/src/tar: default/dir3: Warnung: Funktion acl_from_text 
> > fehlgeschlagen
> > /tmp/tar-1.31/src/tar: default: Warnung: Funktion acl_from_text 
> > fehlgeschlagen
> > /tmp/tar-1.31/src/tar: default: Warnung: Funktion acl_from_text 
> > fehlgeschlagen
>
> This is because we use acl_from_text() without pre-filtering, which
> doesn't accept the fourth UID/GID number value in e.g.
> ACL record 'user:joe:rwx:503' (stored in the archive):
>
>    $ tar -t -vv --acls -f acl-test5.tar
>    ...
>    drwxrwxr-x+ gruenbacher/assis 0 2001-11-04 04:43 default/dir2/
>      a: user::rwx,user:joe:rwx:503,group::r-x,mask::rwx,other::r-x
>    ...
>    $ tar -xf --acls -f acl-test5.tar
>    ...
>    tar: default/dir2: Warning: Cannot acl_from_text: Invalid argument
>    ...

This is the way, it has been negotiated in 2001 with Andreas Gruenbacher from 
Suse and how star implements it since 2001.

The background is that the Solaris tar impementation missed numeric entries and 
thus could not restore ACLs that refer to named entries that do not exist on 
the platform used for extraction.

This was after a discussion with Andreas Gruenbacher during summer 2001 on how 
to define a text format that allows to support the master ACL-on-UFS 
implementation from Solaris that was the base for the withdrawn POSIX proposal
as well as the differing Linux implementation and AIX, HP-UX, IRIX, True64...

The text format for the historical ACL system in star did never change since 
the impementation was first introduced into SCCS in November 2001.

In order to allow other people to implement a compatible interface, we created 
the reference archives at the same time and made them available via ftp.

After some discussions, Sun even added a related ACL_APPEND_ID flag for
acl_totext() in Spring 2005 to match that star format.

> I did not notice this so far, since we don't add the fourth numeric

Well, it is in the star.4 man page since October 2003 - with bold numeric 
fields. 
See
        sccs get -p -A -m -r1.3 star.4

output:
...
1.3     joerg           03/10/07        .B SCHILY.acl.access
1.3     joerg           03/10/07        (a space has been inserted after the 
equal sign and lines are broken
1.3     joerg           03/10/07        [marked with '\e' ] for readability, 
additional fields in bold):
1.3     joerg           03/10/07        .sp
1.3     joerg           03/10/07        SCHILY.acl.access=      
user::rwx,user:lisa:r\-x:\fB502\fP,\ \e
1.3     joerg           03/10/07                                
group::r\-x,group:toolies:rwx:\fB102\fP,\ \e
1.3     joerg           03/10/07                                
mask::rwx,other::r\-\-x
1.3     joerg           03/10/07        .sp
1.3     joerg           03/10/07        The numerical user and group 
identifiers are essential when restoring a system completely
1.3     joerg           03/10/07        from a backup, as initially the 
name-to-identifier mappings may not be available,
1.3     joerg           03/10/07        and then file ownership restoration 
would not work.
1.3     joerg           03/10/07        .sp
1.3     joerg           03/10/07        As the archive format that is used for 
king up access control lists is compatible
1.3     joerg           03/10/07        with the
1.3     joerg           03/10/07        .B pax
1.3     joerg           03/10/07        archive format, archives created that 
way can be restored by
1.3     joerg           03/10/07        .B star
1.3     joerg           03/10/07        or a POSIX.1-2001 compliant
1.3     joerg           03/10/07        .BR pax .
1.3     joerg           03/10/07        Note that programs other than
1.3     joerg           03/10/07        .B star
1.3     joerg           03/10/07        will ignore the ACL information.
1.1     joerg           03/09/14        .TP
1.1     joerg           03/09/14        .B SCHILY.acl.default
1.3     joerg           03/10/07        The default ACL for a file. See 
1.3     joerg           03/10/07        .B SCHILY.acl.access
1.3     joerg           03/10/07        for more information.
1.3     joerg           03/10/07        .sp
1.3     joerg           03/10/07        This is an example of the format used 
for
1.3     joerg           03/10/07        .B SCHILY.acl.default
1.3     joerg           03/10/07        (a space has been inserted after the 
equal sign and lines are broken
1.3     joerg           03/10/07        [marked with '\e' ] for readability, 
additional fields in bold):
1.3     joerg           03/10/07        .sp
1.3     joerg           03/10/07        SCHILY.acl.default=     
user::rwx,user:lisa:r-x:\fB502\fP,\ \e
1.3     joerg           03/10/07                                
group::r-x,mask::r-x,other::r-x


> argument to the SCHILY.acl.access header;  neither star does that (on
> Linux at least, despite the claim in manual page).

You are mistaken.

The additional UIDs/GIDs however are omitted in case that there is no related 
user 
name entry in the passwd database.

This is what you get from star after extracting the reference file and before 
creating a user "lisa":

77 SCHILY.acl.default=user::rwx,user:502:r-x,group::r-x,mask::r-x,other::r-x

and this what star creates after I added a user "lisa" to the passwd file:

82 
SCHILY.acl.default=user::rwx,user:lisa:r-x:502,group::r-x,mask::r-x,other::r-x

Do you believe, that I need to document that this number may be omitted in case 
that the main user/group field is numeric because a lack of a related passwd 
entry? 

Jörg

-- 
 EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin
    address@hidden (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'