> On Sep 10, 2016, at 05:22, Clemens Lang <c...@macports.org> wrote:
>
> Hi,
>
> On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
>>> As an aside, I'd be in favour of setting up MacPorts such that
>>> ${prefix} is owned by a ${macports_operator} who's got admin rights
>>> (= myself) and reserve use of actual root privilege to those few
>>> ports that require setting up SETUID/GETUID executables or that need
>>> to create users or groups.
>>
>> YES! We should not be needing to do such things as root. That is
>> 100% true, and I am in full support of moving away from that and only
>> using root for activate. We should be able to use fakeroot
>> (https://wiki.debian.org/FakeRoot) for destdir.
>
> Except that fakeroot uses library preloading, a technique that's more or
> less dead on modern OS X thanks to Apple's changes related to SIP:
> DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit set.
> Combine that with every binary in /usr/bin and /bin having the bit, and
> you'll end up the variable being removed on the first invocation of a
> shell (which is basically everywhere in the build systems of our ports).
>
> It can still be done with utter hacks (copying the binary into a file
> without the SIP bit and executing it from there, which we do for trace
> mode), but I have neither seen any other library preloading utility that
> used to work on OS X implement these changes nor convinced any of their
> developers to do so.
>
> Other approaches that would allow simulating permissions, such as Linux'
> user namespaces don't exist on OS X at all. I think it's pretty obvious
> that implementing new code that relies on library preloading is riding a
> dead horse on macOS.No, the DYLD_INSERT_LIBRARIES approach is the right one here. Interested users would need to disable SIP. It would be nice if a mechanism were in place to determine trust of certain libraries in DYLD_INSERT_LIBRARIES. Please file radars and point me to them, so I can make sure they get routed to the right place (likely as dupes, but dupes are very useful "votes" for bugs). Thanks, Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
