> On Oct 3, 2015, at 06:02, Clemens Lang <c...@macports.org> wrote: > > Hi Jeremy, > > ----- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jerem...@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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
