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 <[email protected]> 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/[email protected]: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 >> [email protected] >> https://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
