[OpenIndiana-discuss] libarchive - Solaris ACL support
Martin Matuska
martin at matuska.org
Sat Feb 11 00:42:24 UTC 2017
Hi Gordon,
the format was introduced by Jörg Schilling for his "star" archiver. I
do not know any other cross-platform archivers that store NFSv4 ACLs or
even POSIX.1e ACLs than libarchive and star. All other tools I know are
platform-specific. With my latest changes libarchive (officially
starting with version 3.3) supports NFSv4 ACLs on Mac OS X, FreeBSD and
Illumos (Solaris 10+). Mac OS X support is a bit tricky as they support
only user and group ACEs (no owner@, group@ and everyone@) but other
aspect of NFSv4 ACLs (permissions, inheritance flags) are fully
compatible. They support a mixed uid/gid and GUID environment. As of
POSIX.1e ACLs, libarchive supports these on Linux, FreeBSD and Illumos
(Solaris 10+). The corresponding headers for tar are again Jörg
Schilling's standards SCHILY.acl.access and SCHILY.acl.default.
https://www.mankier.com/5/star#Extended_Tar_(Pax)_Header_Keywords
The advantage of the current implementation is that it is supported by
more than one tool (libarchive and star) and there is already some
cross-platformness.
I haven't thought about Windows support yet - but Windows uses GUID
identifiers. SCHILY.acl.ace doesn't support that together with uid/gid.
To support both UNIX uid/gid and GUID at a time we need to design a new
ACL header for tar.
Cheers,
Martin
On 10.02.2017 16:06, Gordon Ross wrote:
> I also wanted to ask: How widely used is the archive format for these ACLs?
> i.e. are there tools on Windows to create or unpack this archive format?
> (including the ACL data)
>
> Thanks,
> Gordon
>
>
> On Sat, Jan 14, 2017 at 5:14 AM, Alexander Pyhalov <alp at rsu.ru> wrote:
>> On 14.01.2017 01:40, Martin Matuska wrote:
>>> Dear Openindiana developers and users,
>>>
>>> I have fixed compilation issues and finalized Solaris-style ACL support
>>> (POSIX.1e and NFSv4) and added it to libarchive's master branch.
>>> https://github.com/libarchive/libarchive
>>>
>>> Libarchive stores ACLs in tar archives using the SCHILY.acl attributes
>>> (SCHILY.acl.access, SCHILY.acl.default and SCHILY.acl.ace), in a
>>> compatible way with the "star" archiver by Jörg Schilling.
>>>
>>> ACLs that exactly mirror the mode (see acl_is_trivial_np() in FreeBSD)
>>> are treated like no ACLs and are not stored (e.g if there is one
>>> additional ACE or one of the trivial ACEs is modified the whole ACL is
>>> stored).
>>>
>>> I have tested building libarchive with the following dependencies:
>>> developer/build/autoconf
>>> developer/build/automake
>>> developer/build/libtool
>>> developer/build/pkg-config
>>> developer/gcc-5
>>> developer/gnu-binutils
>>> library/lint
>>> system/header
>>>
>> Hello, Martin.
>>
>> I've tried to build updated libarchive and ran tests.
>>
>> 64-bit build faild with
>> /export/home/alp/srcs/oi-userland/components/library/libarchive/libarchive-4e0e76464097783c701721d81da548f263577902/libarchive/archive_read_support_format_xar.c:3065:14:
>> error: ‘used’ may be used uninitialized in this function
>> [-Werror=maybe-uninitialized]
>> xar->offset += used;
>>
>> Had to add the following small fix. Don't know why it fails only on 64-bit
>> build (CFLAGS="-m64 -O3" LDFLAGS=-m64
>> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig"). Both config.h files contain
>> '#define HAVE_LIBXML_XMLREADER_H 1'.
>>
>> ---
>> libarchive-4e0e76464097783c701721d81da548f263577902/libarchive/archive_read_support_format_xar.c.1
>> 2017-01-14 10:54:43.567218339 +0300
>> +++
>> libarchive-4e0e76464097783c701721d81da548f263577902/libarchive/archive_read_support_format_xar.c
>> 2017-01-14 10:54:59.570677400 +0300
>> @@ -3047,7 +3047,7 @@
>> struct xar *xar;
>> const void *d;
>> size_t outbytes;
>> - size_t used;
>> + size_t used = 0;
>> int r;
>>
>> a = (struct archive_read *)context;
>>
>> One test failed, as earlier:
>> Failing tests:
>> 45: test_option_uid_uname (1 failures)
>>
>> So I had to reapply the following patch:
>>
>> ---
>> libarchive-4e0e76464097783c701721d81da548f263577902/tar/test/test_option_uid_uname.c
>> 2017-01-13 13:54:22.000000000 +0300
>> +++ test_option_uid_uname.c 2017-01-14 11:22:34.281040312 +0300
>> @@ -45,25 +45,33 @@
>> /* Again with both --uid and --uname */
>> failure("Error invoking %s c", testprog);
>> assertEqualInt(0,
>> - systemf("%s cf archive2 --uid=18 --uname=foofoofoo
>> --format=ustar file >stdout2.txt 2>stderr2.txt",
>> + systemf("%s cf archive2 --uid=65123 --uname=foofoofoo
>> --format=ustar file >stdout2.txt 2>stderr2.txt",
>> testprog));
>> assertEmptyFile("stdout2.txt");
>> assertEmptyFile("stderr2.txt");
>> data = slurpfile(&s, "archive2");
>> /* Should force uid and uname fields in ustar header. */
>> - assertEqualMem(data + 108, "000022 \0", 8);
>> + assertEqualMem(data + 108, "177143 \0", 8);
>> assertEqualMem(data + 265, "foofoofoo\0", 10);
>> free(data);
>>
>> /* Again with just --uid */
>> failure("Error invoking %s c", testprog);
>> assertEqualInt(0,
>> - systemf("%s cf archive3 --uid=18 --format=ustar file
>>> stdout3.txt 2>stderr3.txt",
>> + /* --numeric-owner would make more sense if wanting to guarantee
>> no
>> + * username in ustar header, otherwise it will automatically be
>> added
>> + * if a user with the same uid exists on the system...
>> + * But for all that I know, the intent is to test under the
>> specific
>> + * scenario of where no user with the specified uid exists on
>> system,
>> + * therefore we'll change uid to a more unlikely one to be found
>> any
>> + * users with on the system...
>> + */
>> + systemf("%s cf archive3 --uid=65123 --format=ustar file
>>> stdout3.txt 2>stderr3.txt",
>> testprog));
>> assertEmptyFile("stdout3.txt");
>> assertEmptyFile("stderr3.txt");
>> data = slurpfile(&s, "archive3");
>> - assertEqualMem(data + 108, "000022 \0", 8);
>> + assertEqualMem(data + 108, "177143 \0", 8);
>> /* Uname field in ustar header should be empty. */
>> assertEqualMem(data + 265, "\0", 1);
>> free(data);
>>
>>
>> With this patch all tests pass.
>>
>> I've tried to play with bsdtar and NFS ACLs.
>>
>> $ mkdir 1
>> $ touch 1/file
>> $ pfexec /usr/bin/chmod A+user:lightdm:rwx:allow 1/file
>> $ /usr/bin/ls -lv 1/file
>> -rw-r--r--+ 1 alp staff 0 Jan 14 12:21 1/file
>> 0:user:lightdm:read_data/write_data/execute:allow
>> 1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
>> /read_attributes/write_attributes/read_acl/write_acl/write_owner
>> /synchronize:allow
>>
>> 2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
>> 3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
>> :allow
>> $ pfexec /usr/bin/tar cpf 1.tar 1/
>> $ cd 2
>> $ pfexec gtar -xpf ../1.tar
>> gtar: 1//file: Unknown file type 'A', extracted as normal file
>> $ rm -fr 1
>> $ pfexec bsdtar -xpf ../1.tar # I suppose, it's expected
>> bsdtar: Solaris NFSv4 ACLs not supported
>> bsdtar: Error exit delayed from previous errors.
>> $ ls -lv 1/file
>> -rw-r--r-- 1 alp staff 0 Jan 14 12:21 1/file
>>
>> OK, let's try only with bsdtar.
>>
>> $ pfexec rm -fr 1 ../1.tar
>> $ cd ..
>> $ pfexec bsdtar cpf 1.tar 1/
>> $ cd 2
>> $ pfexec bsdtar -xpf ../1.tar
>> $ /usr/bin/ls -lv 1/file
>> -rw-r--r--+ 1 alp staff 0 Jan 14 12:21 1/file
>> 0:user:lightdm:read_data/write_data/execute:allow
>> 1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
>> /read_attributes/write_attributes/read_acl/write_acl/write_owner
>> /synchronize:allow
>>
>> 2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
>> 3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
>> :allow
>>
>> Seems to be working...
>>
>> If everyone else is interested in testing updated libarchive, he can use
>> https://github.com/pyhalov/oi-userland/tree/libarchive
>> or install
>> pkg://userland/library/libarchive@3.2.2-2017.0.0.0:20170114T095906Z from
>> http://buildzone.oi-build.r61.net:1000/ .
>>
>> What is about ABI-compatibility? Will new libarchive 3.3 release be
>> ABI-compatible to libarchive 3.1, which we currently use?
>>
>> ---
>> System Administrator of Southern Federal University Computer Center
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
More information about the openindiana-discuss
mailing list