Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

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

After upgrading to ML, I am now getting this message when I try to sudo. I've repaired permissions, rebuilt the dyld cache, and removed the DYLD_LIBRARY_PATH environment variable, all with no success. Met with this message each time:


$ sudo ls

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

Password:


Any help is appreciated.


Thanks!

MacBook Pro, OS X Mountain Lion

Posted on Jul 26, 2012 8:42 PM

Reply
66 replies

Oct 5, 2012 9:51 AM in response to Mark Jalbert

Mark Jalbert wrote:


Sudo always had the sticky bit on Mac OS X.....

Not on any of my systems but sudo does have the suid bit set.

There is obviously some confusion about the sticky bit and the setuid bit.


I see this new message in Mountain Lion. It shouldn't be that big of a deal. I would say that if it is breaking something, then that is something that needs to be fixed. I have some extremely complex Perl scripts all running through launchd and SOAP. Even a single byte printed unexpected to stdout will bring down the whole system. It works fine. If anyone has a system that is more of a hack-job than mine, and this causes a problem, then I feel for you.

Oct 5, 2012 10:34 AM in response to etresoft

There is obviously some confusion about the sticky bit and the setuid bit.

Obvious to you, me, and some others but consider that this thread has over 6,000 views.


I see this new message in Mountain Lion. It shouldn't be that big of a deal. I would say that if it is breaking something, then that is something that needs to be fixed.

I'm not using the latest and greatest OS X though this bug is causing alot of confusion for many users. That in itself warrants a fix.

Oct 5, 2012 11:45 AM in response to Mark Jalbert

Mark Jalbert wrote:


I'm not using the latest and greatest OS X though this bug is causing alot of confusion for many users. That in itself warrants a fix.

I don't know. This looks a lot like a security issue. This is telling the user that you have setup some sort of custom dynamic library environment and that environment is going to be ignored. Why wouldn't a user want to know that?


You can see the change in the source code from Lion to Mountain Lion. Most of the log statements are commented out, but not all.

Oct 5, 2012 3:33 PM in response to etresoft

> Why wouldn't a user want to know that?


Because it's totally uninteresting. The far majority of people simply don't get the message and don't care.


The message is not clarifying anything. It does not explain why having sudo being setuid or setgid (whatever the heck that means!) would result in ignoring specifically those variables (and not other variables).


If you must give that warning, send it to a log file. Unix gurus who care will find it, regular users can continue enjoying non-confusing usage of sudo.



Oct 27, 2012 10:56 AM in response to fried1

Hi, I upgraded to mountain lion today, but still seeing this problem.


I came up with a temporary work around may be slightly better than just turning off DYLD_* vairables. In my case, DYLD_* variables are set for some minor programs that doesn't require `sudo' privillage; so I can safely unset DYLD_* before sudo, and restore them after finishing the sudo jobs. And i got a little script to do this:



in your .profile/.bashrc/.bash_profile (depends on you terminal setting):


# set DYLD_* for my normal programs

DYLD_LIBRARY_PATH='..'


# set an alternative sudo

thesudo()

{

# back up the DYLD_* variables

local BACK=$DYLD_LIBRARY_PATH

# unset DYLD_*

unset DYLD_LIBRARY_PATH

# calling sudo

/usr/bin/sudo "$@"

# restore DYLD_* after sudo finished

export DYLD_LIBRARY_PATH=$BACK

}


# redirect sudo

alias sudo=thesudo


In this way, sudo cannot access my customised DYLD_* paths, but at least other programs can. And if a program requires privallage to run with private library, i can always put those libraries under the standard library path /usr/lib. After all if the library is unsafe, you'd better only keep it to normal programs and set the DYLD_ paths to run them.

Feb 1, 2013 1:08 PM in response to yokyoh1987

Does ANYONE who actually understands unix have a suggested fix for this? Those who keep suggesting commenting out the LD_LIBRARY_PATH or unset LB_LIBRARY_PATH will clearly not be able to understand why their suggetsions are so broken. No point in trying to explain it to them.


Macports is broken for me until I can find some way to correctly sudo with LD_LIBRARY_PATH in tact.


Anyone?

Feb 1, 2013 4:52 PM in response to The Aphorist

Make a wrapper. I haven't tried but I'm thinking this should work:


mv /usr/bin/sudo /usr/bin/sudo-real


Make /usr/bin/sudo an executable shell script owned by root (shouldn't be suid, I think. It would be nice to make it suid so it could log the stupid error to /var/log, but then there'd be all the effort of avoiding making the script itself a security hole.)


#!/bin/sh


SUDO=/usr/bin/sudo-real


exec $SUDU $* 2>> /dev/null #Normal users can't write to /var/log/sudu-wrapper-output

Feb 1, 2013 5:08 PM in response to MrElvey

SOLVED!
Yes, this works.

And it's a CORRECT solution - not as good as having Apple fix the problem, but it's pretty clear that if they were going to fix it, whtey would have by now.

This allows settings to stay enabled, and eliminates the error message.



CAREFUL, though... Be sure to have an open root window so you don't lock yourself out.


This worked for me:


sudo sh

<password entered; results in superuser prompt - #>

mv /usr/bin/sudo /usr/bin/sudo-real


cat > /usr/bin/sudo

#!/bin/sh


SUDO=/usr/bin/sudo-real


exec $SUDU $* 2>> /dev/null #Normal users can't write to /var/log/sudu-wrapper-output



^C

sh-3.2# chmod +x /usr/bin/sudo



Now,

sudo works as it always did.




Wow, that was easier than I expected; worked the first time.



Someone want to clean that up so the instructions are so simple and explicit that newbies can follow 'em? (e.g. no ^c, good formatting...) be my guest.


Someone send me a few bucks and I'll make entering this one-liner in Terminal do all the work:

ruby -e "$(curl -fsSkL https://elvey.com/elvey-fix-sudo.sh)"

😁

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

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.