Re: www/serf install permissions fix

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 03/30, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> > Yet another approach might be to say that the macOS system tar is broken
> > in that it preserves the permissions on extraction even though the "-p"
> > option has *not* been given, and use the pkgsrc tar instead.  (I'm
> > guessing here; maybe the pkgsrc tar behaves in the same way?)
> 
> I suspect that will end up being the right think.   You can change
> definitions in tools/mk and/or manually test.

Hmm, pkgsrc-current's archivers/bsdtar (3.3.1) has the same problem when
run as root:

===
# /opt/pkg/bin/bsdtar --version
bsdtar 3.3.1 - libarchive 3.3.1 zlib/1.2.8 bz2lib/1.0.6
# umask
022
# cd /tmp
# bzcat /pkg_comp/distfiles/serf-1.3.9.tar.bz2 | /opt/pkg/bin/bsdtar -xf -
mink# ls -alF serf-1.3.9
total 496
drwxrwxrwx  21 1000  1000     714 Aug 29  2016 ./
drwxrwxrwt   7 root  wheel    238 Mar 30 17:28 ../
-rw-rw-rw-   1 1000  1000   14372 Aug 29  2016 CHANGES
-rw-rw-rw-   1 1000  1000   11357 Aug 26  2007 LICENSE
-rw-rw-rw-   1 1000  1000     287 Sep 17  2015 NOTICE
-rw-rw-rw-   1 1000  1000    2842 Sep 17  2015 README
-rw-rw-rw-   1 1000  1000   17388 Sep 17  2015 SConstruct
-rw-rw-rw-   1 1000  1000     520 Oct 17  2015 STATUS
drwxrwxrwx  10 1000  1000     340 Aug 29  2016 auth/
drwxrwxrwx  21 1000  1000     714 Aug 29  2016 buckets/
drwxrwxrwx   5 1000  1000     170 Aug 29  2016 build/
-rw-rw-rw-   1 1000  1000   11892 Oct 17  2015 context.c
-rw-rw-rw-   1 1000  1000    5880 Aug 26  2007 design-guide.txt
-rw-rw-rw-   1 1000  1000    4380 Sep 17  2015 incoming.c
-rw-rw-rw-   1 1000  1000   58625 Oct 17  2015 outgoing.c
-rw-rw-rw-   1 1000  1000   39346 Sep 17  2015 serf.h
-rw-rw-rw-   1 1000  1000   21225 Sep 17  2015 serf_bucket_types.h
-rw-rw-rw-   1 1000  1000    8787 Sep 17  2015 serf_bucket_util.h
-rw-rw-rw-   1 1000  1000   15934 Sep 17  2015 serf_private.h
-rw-rw-rw-   1 1000  1000    7291 Sep 17  2015 ssltunnel.c
drwxrwxrwx  22 1000  1000     748 Aug 29  2016 test/
===

Also, since I haven't stated it already, the macOS Sierra tar is bsdtar
2.8.3:

===
# /usr/bin/tar --version
bsdtar 2.8.3 - libarchive 2.8.3
===

So, using the pkgsrc archivers/bsdtar instead of the macOS system bsdtar
won't solve the problem.

I tried the same test on NetBSD 6 stable using the base system tar
(i.e., /bin/tar), and it worked as expected.  That is, when run as root
with umask 022, it did *not* create the extracted directories and files
as group- and world-writable.  It also did not preserve the user and
group IDs.

The macOS system bsdtar man page has this to say about the "-p" option:

  -p      (x mode only) Preserve file permissions.  Attempt to restore the
          full permissions, including owner, file modes, file flags and
          ACLs, if available, for each item extracted from the archive.  By
          default, newly-created files are owned by the user running tar,
          the file mode is restored for newly-created regular files, and
          all other types of entries receive default permissions.  If tar
          is being run by root, the default is to restore the owner unless
          the -o option is also specified.

The wording is a bit confusing when it says "by default," but I assume
that means, "by default *when* the '-p' option is specified," and I
assume it's drawing a contrast with the behavior of restoring the owner
when run by root, and it's not talking about the default behavior when
the "-p" option is not specified.

What should be done?  Try yet another pkgsrc tar (e.g., archivers/gtar)?
Fix permissions after extraction (but, as you pointed out, there is the
security issue with the window of group- and world-writable before the
fix-up)?

Thanks!

Lewis