Darwin Version

[Jeremy Huddleston Sequoia]

> On Oct 3, 2015, at 06:02, Clemens Lang <cal at macports.org> wrote:
> 
> Hi Jeremy,
> 
> ----- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jeremyhu at apple.com wrote:
> 
>>> In theory, we have a solution for this problem: trace mode hides anything from
>>> a port's build system that doesn't come with the system and is not in the list
>>> of dependencies, so *in theory* we could replace migration with
>>> sudo port -t upgrade outdated,
>>> and in fact, I successfully tested this during the last OS upgrade. With the
>>> upgrade to El Capitan, though, Apple's System Integrity Protection actually
>>> breaks trace mode (Yay!), so this not an option, leading us to recommend the
>>> migration procedure.
>> 
>> How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
>> followup on that.
> 
> DYLD_ variables are stripped from the environment when executing binaries under
> SIP. That no longer allows us to preload our tracing library into lots and lots
> of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,
> etc.

Ah, that, yes.

> My impression is that this was a deliberate security decision to make sure the
> binary you are executing is actually the one protected by SIP and the exact
> version Apple provided. Please correct me if this assumption is wrong.

This was unfortunate fallout from the hardening effort and is something that we're aware of and looking into.

> For now, I think trace mode can be modified to work around this limitation by
> keeping a shadow copy of all binaries under SIP it wants to execute; since we
> wrap posix_spawn and execve, we can determine whether the executed binary has
> SIP enabled, copy it if that's the case, and run the copy instead,
> circumventing the security measures.
> 
> Btw, what I would actually consider a bug is that running /usr/bin/env (or
> printenv) now no longer show any DYLD_* variables that may be set in your
> environment. Previously we would ask users to run env | grep DYLD_ to check
> for environment variables if they had trouble executing binaries installed
> using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
> even though that's not the same.

Yes, that's basically the same issue.  The DYLD_ environment variables are stripped out when executing system binaries.  /usr/bin/env, /bin/bash, etc are system binaries.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20151003/ae662ee4/attachment.p7s>