1 2 3 4 5 Previous Next 64 Replies Latest reply: May 31, 2013 8:13 AM by bjiibj Go to original post
  • 45. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

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

     

  • 46. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    zenuz Level 1 Level 1 (0 points)

    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

  • 47. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

    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.

  • 48. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

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

  • 49. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    scalz8 Level 1 Level 1 (5 points)

    Many thanks!

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

  • 51. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

    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

  • 52. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    kenny66 Level 1 Level 1 (0 points)

    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.

  • 53. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

    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.

  • 54. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    darkwater42 Level 1 Level 1 (0 points)

    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.

  • 55. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    coredumperror Level 1 Level 1 (0 points)

    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.

  • 56. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    MrElvey Level 1 Level 1 (25 points)

    Nice improvement, Doug.

     

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

  • 57. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    darkwater42 Level 1 Level 1 (0 points)

    You're welcome!

     

    And thanks!

     

    |>oug

  • 58. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    coredumperror Level 1 Level 1 (0 points)

    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.

  • 59. Re: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
    darkwater42 Level 1 Level 1 (0 points)

    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