OS X 10.8 : dyld: DYLD_ environment variables being ignored because main executable is setuid or setgid

[derekbrokeit]

In OS X, ever since the Mountain Lion update, there has been a problem with the used of dynamic library variables as discussed in the README.

The error looks like this: dyld: DYLD_ environment variables being ignored because main executable (/bin/ps) is setuid or setgid

A recent update by apple made this problem go away for sudo, but it persists for other programs that are considered setuid or setgid (e.g. ps). I am not certain if this is a bug for Apple to fix or if we need to proceed with loading these libraries in a new way since Mountain Lion, but I thought I should post it here in case someone had an idea or a work around.

[cehoffman]

Maybe you've found a workaround for this or just disabled stderred, but I finally got around to exploring ways around this.

What I've come up with to combat this problem is to make aliases for all the commands that are setuid/setgid which removes the DYLD_INSERT_LIBRARIES environment variable before calling the executable and putting it into my profile. For ps this looks like alias ps="env -u DYLD_INSERT_LIBRARIES ps".

Thankfully using zsh it was easy to find all the executables in my path which had either of those states using ls $path/*(s) $path/*(S) and then create aliases for them. For the lazy this is my end product.

alias ps="env -u DYLD_INSERT_LIBRARIES ps"
alias rcp="env -u DYLD_INSERT_LIBRARIES rcp"
alias at="env -u DYLD_INSERT_LIBRARIES at"
alias atq="env -u DYLD_INSERT_LIBRARIES atq"
alias atrm="env -u DYLD_INSERT_LIBRARIES atrm"
alias batch="env -u DYLD_INSERT_LIBRARIES batch"
alias crontab="env -u DYLD_INSERT_LIBRARIES crontab"
alias ipcs="env -u DYLD_INSERT_LIBRARIES ipcs"
alias lockfile="env -u DYLD_INSERT_LIBRARIES lockfile"
alias login="env -u DYLD_INSERT_LIBRARIES login"
alias newgrp="env -u DYLD_INSERT_LIBRARIES newgrp"
alias procmail="env -u DYLD_INSERT_LIBRARIES procmail"
alias quota="env -u DYLD_INSERT_LIBRARIES quota"
alias rlogin="env -u DYLD_INSERT_LIBRARIES rlogin"
alias rsh="env -u DYLD_INSERT_LIBRARIES rsh"
alias su="env -u DYLD_INSERT_LIBRARIES su"
alias sudo="env -u DYLD_INSERT_LIBRARIES sudo"
alias top="env -u DYLD_INSERT_LIBRARIES top"
alias wall="env -u DYLD_INSERT_LIBRARIES wall"
alias write="env -u DYLD_INSERT_LIBRARIES write"
alias postdrop="env -u DYLD_INSERT_LIBRARIES postdrop"
alias postqueue="env -u DYLD_INSERT_LIBRARIES postqueue"
alias scselect="env -u DYLD_INSERT_LIBRARIES scselect"
alias traceroute="env -u DYLD_INSERT_LIBRARIES traceroute"
alias traceroute6="env -u DYLD_INSERT_LIBRARIES traceroute6"

[cehoffman]

Just realized it may be worth noting that what Apple has done is plug a security hole which allowed programs with superuser privileges to be compromised using the dynamic linker's ability to inject code at runtime through environment variables. There isn't a way around this for stderred since this is exactly the part of the dynamic linker stderred is leveraging.

[derekbrokeit]

Thanks for the clarification, I previoulsy didn't know why the behavior had changed. Also, thanks for sharing those aliases, I was too lazy to figure them all out on my own and had only been using sudo and ps aliases until now :)

Also, for what it's worth, I didn't know zsh could search the path in that way. Thanks on all accounts!

[evandrix]

@cehoffman: thanks, this list of env unsets is helpful.

[kimbakat]

Could someone leave details and "step by step" instructions for the rest of us on this fix?
Thanks

[derekbrokeit]

@kimbakat , stick those aliases in your ~/.${SHELL}rc file and restart your shell (or reload it source ~/.${SHELL}rc). Then you should be able to use those functions without the annoying error. Hope that helps

[kimbakat]

.....and precisely...how do I do that?
....which is why I expressed the "Step by Step" request to go with it...

Seriously..I need it.