I wrote:
> I recall that we figured out awhile ago that the environment gets trimmed
> when make (or whatever) executes some command via the shell; seemingly,
> Apple has decided that /bin/sh is a security-critical program that mustn't
> be run with a non-default DYLD_LIBRARY_PATH. Dunno if that helps you
> find where the damage is done exactly.
BTW, here's the evidence for this theory:
[tgl@pro ~]$ cat checkenv.c
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char **argv)
{
char *pth = getenv("DYLD_LIBRARY_PATH");
if (pth)
printf("DYLD_LIBRARY_PATH = %s\n", pth);
else
printf("DYLD_LIBRARY_PATH is unset\n");
return 0;
}
[tgl@pro ~]$ gcc checkenv.c
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH is unset
[tgl@pro ~]$ export DYLD_LIBRARY_PATH=/Users/tgl/pginstall/lib
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
[tgl@pro ~]$ sh -c ./a.out
DYLD_LIBRARY_PATH is unset
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
[tgl@pro ~]$ bash -c ./a.out
DYLD_LIBRARY_PATH is unset
You have to check the environment using an "unprivileged" program.
If you try to examine the environment using, say, "env", you will get
very misleading results. AFAICT, /usr/bin/env is *also* considered
security-critical, because I cannot get it to ever report that
DYLD_LIBRARY_PATH is set.
Hmm ... /usr/bin/perl seems to act the same way. It can see
ENV{'PATH'} but not ENV{'DYLD_LIBRARY_PATH'}.
This may indicate that they've applied this policy on a blanket
basis to everything in /bin and /usr/bin (and other system
directories, maybe), rather than singling out the shell.
regards, tom lane
