Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 05:22, Clemens Lang <cal at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160910/26e757a4/attachment.p7s>