[OpenIndiana-discuss] libarchive - Solaris ACL support
Gordon Ross
gordon.w.ross at gmail.com
Fri Feb 10 15:06:20 UTC 2017
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