dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid

stlandroidfan, I think it is a mistake to mess with the original sudo for the reason that you inadvertently discovered. Instead you should make the sudo wrapper as I documented, and just put it in your path prior to the real sudo. (This won't cure the annoying message 100% of the time, as some programs will still run /usr/bin/sudo, rather than what is in your path, but it will fix the problem for the most common use-case of typing sudo at the shell.)

One reason for not messing with the original sudo is that if you just look at a program that has suid permissions cross-eyed, Unix will remove the suid permissions from the program as a security feature. But then suid is nothing without having suid permisssions.

And once sudo no longer has suid permissions, it's hard to put this permission back. It can be done, and this is how:

$ open "/System/Library/CoreServices/Directory Utility.App"

In this program do Edit -> Enable Root User. (You'll have to click on the little padlock first.)

Now you can set a root password, su to root using the "su" program, fix the file permissions, try out sudo in a different terminal window to make sure that sudo works (type "whoami" at the shell first to make sure that you're not root), and then disable the root login again in the Directory Utility app.

|>oug

Thanks a lot, darkwater42.

I followed your instructions but in the mean time, my Terminal is now completely broken. So even though I set a root password in the Directory Utility App, I cannot su from Terminal.

login(583,0x7fff7b39e180) malloc: *** error for object 0x7fa220c31de0: pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug

[Process completed]

When I try to open it, it fails with the above message.

I'm thinking I should just clean install Mountain Lion. I shouldn't have been messing with this stuff in the first place. I upgraded from Lion to Mountain Lion without a clean install, so here's an opportunity to clean up my hard drive of junk and to learn a great lesson in not messing with the system.

That's very strange, stlandroidfan. Enabling the root user should never cause any harm at all (except that if you don't pick a good password, someone might break into your computer).

Have you tried rebooting your computer? I shouldn't think that the problem you are seeing has anything to do with either sudo or there being a root user. On the other hand, you may have messed something else up without realizing it. E.g., deleting an important system file, and then it would be nigh impossible to recover without a reinstall.

|>oug

It's just an overzealous warning on the part of OS X's dyld library. My personal opinion is that the warning should not be printed out ever unless a variable like DYLD_DEBUG is set. This is the kind of warning that should only be interested to an expert trying to debug dyld behavior and thus should be hidden behind a conditional environment variable like DYLD_DEBUG.

At any rate, I strongly disagree with the approach of messing with installed executables on your system as a means of implementing a workaround. I agree with whoever posted that the most convenient mechanism for doing this is to put a wrapper program in your PATH somewhere before the real program. This is by far the safest way as you cannot possible screw up your system this way. At the worst you just have to remove the wrapper program if something goes bad.

Here is how I did it:

bji$ cat > /Users/bji/bin/sudo

#!/bin/sh

unset DYLD_LIBRARY_PATH

unset DYLD_FALLBACK_LIBRARY_PATH

exec /usr/bin/sudo "$@"

^D

bji$ chmod +x ~/bin/sudo

Of course my user name is 'bji' and I have /Users/bji/bin first in my PATH.

I also did the same for other programs that I found that were setuid root. I was lazy when finding these files and just used:

ls -l /bin | grep 'rws'

ls -l /usr/bin | grep 'rws'

There are arguments to the 'find' command that would be more comprehensive but I didn't feel like reading the man page to figure them out.

Does anyone know if using OnyX Maintenance tab functions could have caused this?

"dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid"

I'm on ML 10.8.5 and I have the same in the terminal.

ALSO...as a side note...my DropBox app won't launch unless I go into the contents and click on the executable in there..it opens up in Terminal and runs properly till I close the terminal..then all Dropbox functions stop.

I've tried some of the solutions here..nothing worked for me.

Any input would be great.

Thanks for the info on the argument expansion!

I found a thread on StackOverflow about this, recommending the wrapper be a bash function. I've got this in my ~/.bashrc:

sudo () { ( unset LD_LIBRARY_PATH DYLD_LIBRARY_PATH; exec command sudo "$@" ) }

Which does the same kind of wrapper, but doesn't require you to mess with PATH, and is a one-liner which I find aesthetically pleasing. :-)

Here's the Stack Overflow thread:

http://stackoverflow.com/questions/12064725/dyld-dyld-environment-variables-bein g-ignored-because-main-executable-usr-bi