16

In shell scripts used for unit testing with dynamic libraries in a directory other than the typical @rpath, I have previously been able to set DYLD_FALLBACK_LIBRARY_PATH to set the directory containing the libraries. Under 10.11.1, bash seems to ignore attempts to set this environment variable:

$ sh -x testscript.sh
+ DYLD_FALLBACK_LIBRARY_PATH=/Users/something/testinglibs
+ export DYLD_FALLBACK_LIBRARY_PATH
+ exec printenv

and DYLD_FALLBACK_LIBRARY_PATH is not present in printenv's output.

Is this a security-related hack in 10.11's shell? I haven't been able to find this change documented in man pages or online.

Improve this question
2
  • Would the install_name_tool help?
    – Saaru Lindestøkke
    Commented Feb 28, 2017 at 12:39
  • 2
    Sure, install_name_tool is a permanent solution (and I've actually scripted it to setup the build environment). For quick testing and debugging in a development environment, it's a hassle to have to make temporary copies of libraries, hack in @rpath changes, and then possibly forget about the manual change. DYLD_FALLBACK_LIBRARY_PATH and DYLD_LIBRARY_PATH were handy for these occasional dev/test cycles.
    – Guy
    Commented Mar 1, 2017 at 14:16

1 Answer 1

Reset to default
12

This is System Integrity Protection introduced in El Capitan

Documentation is in this from Apple

Basically any Apple supplied OS X executables are protected. and (from an earlier document)

Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

In this case sh is protected

Improve this answer
6
  • Thanks for the pointer! I had been focused on the kernel and other filesystem protections in SIP. Did not notice this change.
    – Guy
    Commented Oct 28, 2015 at 14:43
  • 3
    Ok, this explains the origin of the phenomenon, but how the heck are we now supposed to test non-installed libraries? I mean, how can we write make check on El Capitan when shared libs are needed?
    – akim
    Commented Nov 9, 2015 at 16:52
  • Most make via autoconf should end up in /usr/local which is still writeable - if they try for anywhere else under /usr I would question the author's knowledge of OS X (or Unix)
    – mmmmmm
    Commented Nov 9, 2015 at 17:12
  • If anyone finds this after wasting time trying to understand why the dyld environment vars were disappearing, consider filing a bug with Apple to make them document the dyld/SIP interaction. I did already, and the bug got number rdar://30755019. (I'm hoping that they will then think to document other such traps...)
    – hmijail
    Commented Feb 28, 2017 at 10:39
  • 1
    (I meant document the SIP interaction in the dyld manpage, which as of this writing is totally mum about it)
    – hmijail
    Commented Feb 28, 2017 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .