Today I did a crazy thing: I changed the permissions for all files/folders under /usr/bin/ as 777. Read, write and execute. Since then I am not able to login as sudo. It simply throws

sudo : must be setuid root

I read in a post:

Reboot the computer,choose recovery console and type the following commands

chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo

Reboot the machine.

But the problem is that I am not able to login as sudo to reboot. For rebooting, the user has to be a superuser, e.g. root. Neither do I know the password for sudo. Is there any any way I can solve this?

  • Please mention your OS. Have you tried to su using root's password? – Daniel Beck Jan 12 '12 at 10:13
  • 1
    Also, how is it possible for you to change /usr/bin to 777 without knowing a sudo password? – slhck Jan 12 '12 at 10:19
  • can you post what output you get with "ls -l /usr/bin/sudo" – daya Jan 12 '12 at 10:22
  • 3
    I suggest you request support from the server administrators or other support staff on site. If it were possible to do this remotely, with neither sudo nor the root password, it'd be a serious security problem. The only way to do this yourself is to exploit security vulnerabilities like other setuid binaries, scripts that are executed as root on a schedule and which you can edit, etc. – Daniel Beck Jan 12 '12 at 10:39
  • 1
    You need to understand that there is no such thing as a sudo user. If you need temporary root privileges as your normal user, you use sudo (superuserdo) and provide your user's password to run a command as root. To login as root use su and provide the password to the root user. – user111228 Jan 12 '12 at 13:29

The superuser is probably taking you (and /bin/su) out of /etc/sudoers (and probably /etc/passwd) as I type this.

If you don't know the superuser password, in order to switch to the superuser account using /bin/su, then you obviously aren't the actual superuser and that is someone else. The person to fix this is the actual superuser, because you've opened a massive security hole and created a right mess. The actual superuser, upon seeing this mess, has probably gone into BOFH mode and is busy removing your ability to ever again run things under the aegis of the superuser account, given what happens when you do.

Basically, you've opened a window where anyone with an account on the machine can compromise it and gain superuser privileges almost trivially easily. (Some executables regularly run under the aegis of the superuser account, in response to cron jobs and the like, are now world-writable.) Tidying this up safely is a whole lot of work, because one has to work on the basis that any executable anywhere on the system is potentially compromised by now. Anyone who could remotely log in to an account on the machine via SSH, or exploit any other means of gaining shell access as an ordinary user, could have compromised it.

Your two-liner from an unnamed post on a discussion forum is entirely missing the security ramifications of what you've done. But that is in part because it addresses a different situation. The posts you are no doubt looking at are where people have changed the ownership of /usr/bin/sudo, and have not made it world-writable like you have.

Your superuser, if xe knows xyr stuff, will not miss the security ramifications. But xe won't be happy with how much work you've just created for xem.

For the poor superuser's benefit:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.