"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes: > 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. Agreed. > > 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. > /pkg_comp/pkgsrc/mk/extract/extract -t /usr/bin/tar /pkg_comp/distfiles/serf-1.3.9.tar.bz2 > > 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 > === One question is how we feel about distfiles with world-writable .h files. It feels like a bug, but it also doesn't seem realistic to expect upstreams to fix this sufficiently aggressively that we can just consider these broken. Another is about unpacking a distfile that leads to a group/world writable file. That's a security issue, and if we decide not to blame the distfile we can blame the unpacking tool. Then, there's blaming build systems that copy .h files into the destdir without fixing the modes. That's a bug, but also hard to fix in general. > 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. Yes, but there is the security issue of them being writable. > Another approach, more global in nature, might be to make pkgsrc fix the > permissions in the extract phase for all distfiles extractions. Yes, but I think that still leaves a window for manipulation. > 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. We could also add a check for bad permissions in the workdir after unpacking, as part of PKG_DEVELOPER. That would probably surface the issue on other platforms.
Attachment:
signature.asc
Description: PGP signature