Jeremy Huddleston Sequoia
jeremyhu at apple.com
Sat Oct 3 08:37:37 PDT 2015
> 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,
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...
Size: 4109 bytes
Desc: not available
More information about the macports-users