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

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

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

stat -r /usr/bin/sudo
234881026 136015 0104511 1 0 0 0 272384 1349387464 1245738542 1324302906 1245738542 4096 232 32 /usr/bin/sudo

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.

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.

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.

> 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.

Since installing rhe 10.8.2 Suplemental Update 1.0 the warnings are now gone!

Which build number do you have? I updated and the warning are still there:

$ /usr/bin/sw_vers ProductName: Mac OS X ProductVersion: 10.8.2 BuildVersion: 12C60 $ ps dyld: DYLD_ environment variables being ignored because main executable (/bin/ps) is setuid or setgid PID TTY TIME CMD 6410 ttys000 0:00.26 -bash ...

Same BuildVersion as MatteoCorti and same warning. I'll continue to follow this thread closely.

There should be a way to flag messages for moderation like the above by Dylan Clendeninthat are certain to cause harm if followed other forums have that feature. It really needs to be nuked. The follow-up comments are good, but many folks leap, and then look...

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.

i tried:

su -

chmod u-s ps

it works for ps command

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?

A fix for what? There are few people who have even noticed this and fewer still who are impacted in any meaningful way. If you are having a specific problem, start your own thread to discuss it at a higher level instead of focusing on this one, tiny tangent.

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

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)"

😁