3

On a remote server, it used to be the case that it was possible to execute a command as another user using the sudo -u command but lately, I have been unable to accomplish this. When I do I receive the following error:

sudo -u lool ./autogen.sh 
/var/tmp/scltjLjKc: line 8: -u: command not found

so I'm having to resort sudo-ing to root then su into the user before being able to execute the command. What could be the possible cause of this?

Dark Star1
  • 1,355
  • 6
  • 21
  • 37
  • add your user into sudoer: run visudo – Orphans Nov 08 '16 at 15:32
  • Do a `which sudo`, what is the path of the sudo binary you are running? What is the contents of that file `/var/tmp/scltjLjKc`? What you are showing us is unusual, I have never seen output like that before from sudo. – Zoredache Nov 08 '16 at 19:20
  • 5
    BTW, have you seen these? https://bugzilla.redhat.com/show_bug.cgi?id=1319936 http://unix.stackexchange.com/questions/192809/sudo-i-returns-an-error? Those seem to show that having the package `devtoolset` installed gives you a crappy sudo wrapper that breaks things. – Zoredache Nov 08 '16 at 19:24
  • @Zoredache Thanks. I'll use the link to look into the issue in a day or so. – Dark Star1 Nov 09 '16 at 13:01

1 Answers1

2

Since this never got an answer, the comment by Zoredache is correct. Installing one of the devtoolset-* software collections is responsible for this problem. I can't imagine who thought hijacking sudo was a reasonable or responsible thing to do.

The quickest way to resolve it, without messing with your path and possibly breaking the development tools you've just installed is to do this:

# alter the file, so that it won't get overwritten by updates
echo '### garbage ####' >> /opt/rh/devtoolset-2/root/usr/bin/sudo
# make it non-executable so your system won't try to run it
chmod -x /opt/rh/devtoolset-2/root/usr/bin/sudo

Of course, replace devtoolset-2 with whatever version you're using.

miken32
  • 930
  • 1
  • 11
  • 32