tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: www/serf install permissions fix



On 03/28, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> > I noticed that the header files in the distribution file are
> > world-writable and that they are world-writable for me after the extract
> > phase.  Could this be a difference?
> > 
> > ===
> > # bmake extract
> > # ls -al /pkg_comp/work/pkg/www/serf/work/serf-1.3.9/*.h
> > -rw-rw-rw-  1 1000  1000  39346 Sep 17  2015 /pkg_comp/work/pkg/www/serf/work/serf-1.3.9/serf.h
> > -rw-rw-rw-  1 1000  1000  21225 Sep 17  2015 /pkg_comp/work/pkg/www/serf/work/serf-1.3.9/serf_bucket_types.h
> > -rw-rw-rw-  1 1000  1000   8787 Sep 17  2015 /pkg_comp/work/pkg/www/serf/work/serf-1.3.9/serf_bucket_util.h
> > -rw-rw-rw-  1 1000  1000  15934 Sep 17  2015 /pkg_comp/work/pkg/www/serf/work/serf-1.3.9/serf_private.h
> > ===
> 
> I see that too.  For some reason people think it's ok to generate
> distfiles on windos :-) (Really, I have no idea what happened before,
> but I do remember an issue with odd permissions in distfiles and a
> decision to avoid running make dist on windows.)
> 
> But when I do "make extract" I end up with 644.  If I set uamsk to 0,
> they are 666.
> 
> So I think tar is fixing up the permissions, perhaps because the UID is
> different.
> 
> As root, it might not fix permissions, because it can set the owner
> also.
> 
> So this is perhaps an extraction issue, more than a umask build issue.

I guess it depends on how you look at it, but it's clear that there is
a difference when building as root vs. nonroot, so it just needs to be
made clear what the expected behavior is in order to fix it.

I investigated more, and indeed the permissions of the extracted files
are different when extracted as root vs. nonroot.  In both cases the
umask is 022.  For root, it's as shown above.  For nonroot, it's like
what you observed where tar has fixed the permissions.

Invoking "bmake extract" ends up executing the following (simplified;
the actual command is longer because it sets many environment variables,
changes the current working directory to the package work directory,
etc.):

  /pkg_comp/pkgsrc/mk/extract/extract -t /usr/bin/tar /pkg_comp/distfiles/serf-1.3.9.tar.bz2

The extract program ends up executing the following (again simplified):

  bzcat /var/pkg_comp/distfiles/serf-1.3.9.tar.bz2 | /usr/bin/tar -xf -

Executing that, inside or outside the sandbox, has the same behavior
variation when run as root vs. nonroot as follows:

=== root ===
# ls -alF serf-1.3.9/*.h
-rw-rw-rw-  1 1000  1000  39346 Sep 17  2015 serf-1.3.9/serf.h
-rw-rw-rw-  1 1000  1000  21225 Sep 17  2015 serf-1.3.9/serf_bucket_types.h
-rw-rw-rw-  1 1000  1000   8787 Sep 17  2015 serf-1.3.9/serf_bucket_util.h
-rw-rw-rw-  1 1000  1000  15934 Sep 17  2015 serf-1.3.9/serf_private.h
===

=== nonroot ===
% ls -alF serf-1.3.9/*.h
-rw-r--r--  1 jlmuir  wheel  39346 Sep 17  2015 serf-1.3.9/serf.h
-rw-r--r--  1 jlmuir  wheel  21225 Sep 17  2015 serf-1.3.9/serf_bucket_types.h
-rw-r--r--  1 jlmuir  wheel   8787 Sep 17  2015 serf-1.3.9/serf_bucket_util.h
-rw-r--r--  1 jlmuir  wheel  15934 Sep 17  2015 serf-1.3.9/serf_private.h
===

So, I think it just needs to be made clear, does pkgsrc support
building packages as root?  If so, then what is the expectation for
the permissions on extracted files?  The assumption I made with my
previously submitted patch is that there is no expectation; the
permissions can be whatever, and the permissions will be set correctly
when the files are installed.  The patch just corrects the permissions
on the files once they are installed.  That seemed like the most
straightforward approach.

Another approach, more global in nature, might be to make pkgsrc fix the
permissions in the extract phase for all distfiles extractions.

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?)

Thanks!

Lewis


Home | Main Index | Thread Index | Old Index