3

Occasionally when I export in bash it doesn't give an error but it doesn't set the environment variable either. Here's what I mean:

This works:

bash-3.2$ export DYLD=$ABC_HOME
bash-3.2$ env | grep DYLD
DYLD=/Users/my_username/abc_home

But when I continue, these don't:

bash-3.2$ export DYLD_LIBRARY=$ABC_HOME
bash-3.2$ env | grep DYLD
DYLD=/Users/my_username/abc_home

bash-3.2$ export DYLD_L=$ABC_HOME
bash-3.2$ env | grep DYLD
DYLD=/Users/my_username/abc_home

bash-3.2$ export DYLD_=$ABC_HOME
bash-3.2$ env | grep DYLD
DYLD=/Users/my_username/abc_home

Any idea what I could look at to fix this?

FWIW, other exports with underscores work as expected, but this seems to start failing once I add the underscore in.

Improve this question
14
  • 1
    I don't see that here. What OS is this? OS X I presume? Does this work correctly with non-DYLD prefixes? Could this be an OS X "protection"? Commented Nov 9, 2015 at 19:08
  • 1
    I get a slightly different behavior on an OS X machine, but it suggests there's something special about DYLD names: $ env | grep DYLD dyld: warning, unknown environment variable: DYLD_L dyld: warning, unknown environment variable: DYLD_LIBRARY Commented Nov 9, 2015 at 19:12
  • 1
    Do you see the exported variables if you use the export command to view rhem, rather than env? Commented Nov 9, 2015 at 21:57
  • 1
    @jjjkkklllhhh: I think the link @Etan posted is relevant, but my original idea (which is partially confirmed by your answer) is that environment variables starting DYLD_ are being cleaned from the environment by the installed version of env (or by something else). Commented Nov 10, 2015 at 20:47
  • 1
    @EtanReisner: Yeah, there is actually documentation here. According to that, "When system files are installed, they are marked with a special flag to protect against modification..." Also, directories like /bin and /usr/bin are automatically protected. Finally, "[a]ny dynamic linker ( dyld ) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes." Here, I think the issue is that env is protected. Commented Nov 11, 2015 at 2:52

2 Answers 2

Reset to default
6

This appears to be an OS X protection (added in El Capitan possibly) that prevents these (potentially dangerous) environment variables from being exported to spawned processes.

This thread on the Apple Developer Forums discuss this some.

The official documentation here also documents this briefly:

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

This is indeed added in El Capitan, and can be disabled from the recovery partition with csrutil enable --without debug (the --without option is undocumented).
@4ae1e1 That disables the feature entirely? Is there control over whether a specific executable is in the protected/restricted set?
There is /System/Library/Sandbox/rootless.conf, but I believe it's undocumented, and the conf file itself is under Filesystem Protection of SIP (so you'll have to --without filesystem first to make any changes to it; even then I'm not sure if changes would be picked up, since I never tried).
Found this Apple Developer Forums thread with some QA allegedly from WWDC Security and Privacy Lab.
-2

Try this :

oldifs=$IFS
IFS=$'\n'
export DYLD_LIBRARY=$ABC_HOME
env | grep DYLD
IFS=$oldifs
Improve this answer

1 Comment

Why do you think that will help? (Add the explanation to your answer.)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.