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.

jjjkkklllhhh
  • 31
  • 2
  • 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"? – Etan Reisner Nov 09 '15 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 – davejagoda Nov 09 '15 at 19:12
  • Do curly braces make any difference: `${ABC_HOME}` – ramana_k Nov 09 '15 at 19:13
  • See [this answer](http://stackoverflow.com/a/24320548/1517864) – jayant Nov 09 '15 at 19:13
  • This is really strange! I never noticed this (OS X). It seems to have to do with the specific DYLD prefix. It does not happen with DYLE* etc. – Johannes Overmann Nov 09 '15 at 19:48
  • 1
    Do you see the exported variables if you use the `export` command to view rhem, rather than `env`? – rici Nov 09 '15 at 21:57
  • @rici I do see them when I use `export`. Do you have any idea what might be going on? – jjjkkklllhhh Nov 10 '15 at 09:58
  • @EtanReisner Yup I'm on OS X 10.11.1. I suspect that it's an El Capitan protection because it used to work on earlier versions. – jjjkkklllhhh Nov 10 '15 at 15:30
  • [This thread](https://forums.developer.apple.com/thread/9233) seems fairly relevant. – Etan Reisner Nov 10 '15 at 15:34
  • 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). – rici Nov 10 '15 at 20:47
  • The link seems to indicate that they are being scrubbed from the environment of "protected processes" among which is the shell. So while `export` marks them for export to bash internally it fails to set them in the actual process environment (so `env` doesn't see them). – Etan Reisner Nov 10 '15 at 20:49
  • 1
    @EtanReisner: Yeah, there is actually documentation [here](https://developer.apple.com/library/prerelease/ios/documentation/Security/Conceptual/System_Integrity_Protection_Guide/Introduction/Introduction.html). 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. – rici Nov 11 '15 at 02:52
  • @EtanReisner: Sadly, I no longer have a Mac to play with. – rici Nov 11 '15 at 02:53
  • That's an interesting point. I wonder if `env` or the shell is protected/at "fault" here. @jjjkkklllhhh Do you see the `DYLD_`, etc. values in the output of `tr '\0' '\n' – Etan Reisner Nov 11 '15 at 02:57

2 Answers2

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.

Etan Reisner
  • 77,877
  • 8
  • 106
  • 148
  • 1
    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 Dec 24 '15 at 19:12
  • @4ae1e1 That disables the feature entirely? Is there control over whether a specific executable is in the protected/restricted set? – Etan Reisner Dec 24 '15 at 22:24
  • 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). – 4ae1e1 Dec 24 '15 at 23:24
  • 1
    Found [this Apple Developer Forums thread](https://forums.developer.apple.com/thread/16768) with some QA allegedly from WWDC Security and Privacy Lab. – 4ae1e1 Dec 24 '15 at 23:38
-2

Try this :

oldifs=$IFS
IFS=$'\n'
export DYLD_LIBRARY=$ABC_HOME
env | grep DYLD
IFS=$oldifs
michael501
  • 1,452
  • 9
  • 18