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

This solved my problem as well.

I just had to correct a typo, changing SUDU to SUDO in:

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

Then I had to fix the permissions in the new sudo file. I used Disk Utility for that.

Thanks for the support

Ooh, don't know how that typo managed to get in there. Good catch and sorry.

More seriously though, there's another problem.

My sudo wrapper has some bugs. It doesn't work in some complicated situations: It may fail if there's file redirection going on, or subshells are being launched with it.

so, for example this alias I wrote doen't work after my sudo wrapper has been put in place:

alias du--sortedK20asRoot='sudo sh -c '\''(test -r du--sortedALLk && mv du--sortedALLk du--sortedALLk.8421.bak) ; (du -skx * .??* | sort -n | tee du--sortedALLk | tail -20) ; chown $USER du--sortedALLk'\'''

I'm not quite sure what's going on or how to fix it. But it's at least a partial fix.
I've put the original back in place and I'm renaming my wrapper to mysudu, for now.

That alias came across weird. Here it is again:

alias du--sortedK20asRoot="sudo sh -c '(test -r du--sortedALLk && mv du--sortedALLk du--sortedALLk.$RANDOM.bak) ; (du -skx * .??* | sort -n | tee du--sortedALLk | tail -20) ; chown elvey du--sortedALLk'"

Many thanks!

This solved my problem too. Also in csh (simply by substituting sh in csh) it works! :-)

Works for me!

SOLVED! (revised, cleaned up repost w/ added CAVEAT)

Yes, this works.

It's a MORE CORRECT solution - not as good as having Apple fix the problem, but it's pretty clear that if they were going to fix it, they 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. (^C means enter Ctrl-C to terminate the 'cat' command.)

This worked for me: (option A)

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 $SUDO $* 2>> /dev/null #Normal users can't write to /var/log/sudu-wrapper-output

^C

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

Now,

mysudo works as sudo always did.

Please click 'Like' if this helped you.

CAVEAT: You can simply name it sudo, not mysudo, but the reason I name it mysudo is that my sudo wrapper has some bugs. It doesn't work in some complicated situations: It may fail if there's file redirection going on, or subshells are being launched with it.

so, for example this alias I wrote didn't work after my sudo wrapper had been put in place as 'sudo' (so I moved it to mysudo):

alias du--sortedK20asRoot="sudo sh -c '(test -r du--sortedALLk && mv du--sortedALLk du--sortedALLk.$RANDOM.bak) ; (du -skx * .??* | sort -n | tee du--sortedALLk | tail -20) ; chown elvey du--sortedALLk'"

If you want to be more cautious, do this instead: (option B)

sudo sh

<password entered; results in superuser prompt - #; no mv>

cat > /usr/bin/mysudo

#!/bin/sh

SUDO=/usr/bin/sudo-real

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

^C

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

You're gonna miss error messages.

E.g.,

sudo ps -p 4325324

You will get

ps: process id too large: 4325324

But,

mysudo ps -p 4325324

gives no output at all.

True, Kenny. Swapping in this line fixes that:

exec $SUDO $* 2>&1 | grep -v "DYLD_ environment variables being ignored"

It looks like it could be further improved using the info here, likely to 100% fixed.

Sigh. This wrapper script is heading in the right direction, but redirecting i/o in it is egregiously bad, and unecessary to boot. Instead the wrapper script should just unset the environment variables that sudo is complaining about, since sudo is going to unset them anyway. Here's what the wrapper script should look like:

#!/bin/sh

set -ue

unset DYLD_LIBRARY_PATH

unset LD_LIBRARY_PATH

exec /usr/bin/sudo ${1+"$@"}

|>oug

P.S. Also $* is wrong in the previously presented wrapper script. You must use what I have included here instead.

Thank you! This is exactly what I was looking for.

However, I'm curious: What's the "|>oug" bit right after the script in your post? I'm afraid it might be some unformatted part of the script.

Nice improvement, Doug.

Core, it's not a typo; it's his 'sig'. Google ASCII signature art...

You're welcome!

And thanks!

|>oug

I'm curious: why is $* wrong, and ${1+"$@"} correct? I tried googling it, which led me to the man page for bash's Parameter Expansion, but it didn't really help me understand why ${1+"$@"} is more appropriate.

EDIT: Upon further purusal of the google results, I ran across this post on the Unix/Linux StackExchange. It says that ${1+"$@"} hasn't been necessary for decades, because it was a workaround for a bug in versions of Bourne Shell from before the 80s. In modern shells, it's the exact same thing as "$@" (quotes required).

So, ultimately, I think this version of darkwater42's script would be less confusing

#!/bin/sh

set -ue

unset DYLD_LIBRARY_PATH

unset LD_LIBRARY_PATH

exec /usr/bin/sudo "$@"

Also, I couldn't actually use that script when doing a simple sudo command. It seems like Bash (or something about OSX?) always exapnds "sudo true" to "/usr/bin/sudo true", even when a script called 'sudo' is in a folder in your PATH that's before /usr/bin. So to truely "fix" the regular sudo command, you have to do as mentioned earlier in this thread, moving /usr/bin/sudo to /usr/bin/real-sudo, then putting this script in its place, with the last line calling /usr/bin/real-sudo.

Coredumperror, $* is wrong because if you pass in an argument, such as a filename, that has a space in it, then that argument will not be quoted when it is passed into the real sudo, and therefore the space will cause the argument to be seen as two arguments, rather than as a single argument with a space in it. There are other funny characters that will also cause problems unless the arguments are quoted.

"$@" is a special magic construct that will expand all the arguments just like $* would, but it will also automagically wrap them in quotes. Unfortunately, in older shells, if there are no arguments, then "$@" expands into a single empty argument, rather than into no arguments. The ${1+"$@"} version says to only do the expansion if there is at least one argument.

It is true that bash fixed this problem a long time ago, so you can use the simpler form if you know 100% that you are using bash and you know 100% that bash is not running in a Bourne shell compatability mode. But /bin/sh is not always the same as bash, and even when it is, when run as /bin/sh it often runs in a compatability mode where it preserves "features" of older shells the way that they were so older scripts will continue to run properly.

Do it the way I indicated, and it will run unmodified on nearly any Unix computer that has ever existed. If you do it differently, then you're on your own!

As to "sudo true" always running "/usr/bin/sudo", despite having an sudo wrapper in one's path, that is absolutely, positively not the case. Either you don't have your path set up properly, or you didn't set the script to be executable (via "chmod a+x"), or you didn't start up a new shell after putting the sudo wrapper into your personal bin directory. You can also type "hash -r" to an existing bash prompt to get it to update its notion of what's in your path, if you added something new to it since the bash instance was created.

|>oug

I followed this and it screwed up my sudo. I followed the lines exactly and after control^c, the command chmod +x /usr/bin/sudo yielded an error. I freaked out so I deleted the new sudo. I then took the old sudo, now renamed sudo-real - and renamed it back as sudo right from Finder. Now sudo no longer required a password - which is really odd. I know some people might like that, but I preferred it the way it was.

So I restored sudo from Time Machine but from Lion with sudo dating back to 2010.

Now sudo is broken altogether - I get the command sudo: must be setuid root

I am trying to repair disk permissions to see if that helps.

Should I restore Mountain Lion?

How can I reverse this problem?

All I was trying to do is to run JGR from R. The JGR launch script would produce this error: "dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid" and "./JGR.app/Contents/MacOS/JGR: Command not found."

So I was trying to fix that.