2

I ran sudo chmod 777 -R /usr/bin as I had a few programs there I wanted to be able to run with more ease, without continuously entering my root password but now /usr/bin/sudo keeps giving me an error whenever I run sudo. Namely this error:

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

and I am stuck for how to fix this.

Josh Pinto
  • 7,919
  • 3
    Although I have seen some some people claim to recover from such a command, IMO it is easier and faster and more reliable to re-install. Most applications can be run as a normal user, you only need to use sudo if you need to edit or change system files, and changing this breaks linux. – Panther Jun 09 '15 at 03:29
  • Changing a program's permissions to 777 won't help you run it without being root, unless it was actually non-executable (except by root) before. – user253751 Mar 12 '16 at 00:42

2 Answers2

5

The following procedure can also be performed from booting to Recovery Mode choosing Root. Then after booting into root, type in the following to mount the drive in Read / Write so changes can be made:

mount -o remount,rw /

I would recommend following the first answer on this site to boot to a Live CD so that you can mount your hard drive and repair your file(s). Stop after hitting step #5 so that your hard drive is mounted as a root user.

How can I repair grub? (How to get Ubuntu back after installing Windows?)

after the drive is mounted as a root user, you should be able to type in from the terminal window:

chmod 4755 /usr/bin/sudo

to set the setuid back for the sudo file.

The following list is all the files in /usr that should have the setuid set: (I will leave them as a list that you can copy and paste as need be)

chmod 4755 /usr/bin/pkexec
chmod 4755 /usr/bin/sudo
chmod 4755 /usr/bin/mtr
chmod 4755 /usr/bin/traceroute6.iputils
chmod 4755 /usr/bin/gpasswd
chmod 4755 /usr/bin/lppasswd
chmod 4755 /usr/bin/passwd
chmod 4755 /usr/bin/newgrp
chmod 4755 /usr/bin/chsh
chmod 4755 /usr/bin/chfn

EDIT 2:

The following files have permissions of rwxr-sr-x and can be reset by copy and pasting the following into a terminal after getting the host back up: (some might be different then your system)

sudo chmod 2755 /usr/bin/mail-unlock
sudo chmod 2755 /usr/bin/dotlockfile
sudo chmod 2755 /usr/bin/ssh-agent
sudo chmod 2755 /usr/bin/wall
sudo chmod 2755 /usr/bin/dotlock.mailutils
sudo chmod 2755 /usr/bin/chage
sudo chmod 2755 /usr/bin/bsd-write
sudo chmod 2755 /usr/bin/crontab
sudo chmod 2755 /usr/bin/expiry
sudo chmod 2755 /usr/bin/mlocate
sudo chmod 2755 /usr/bin/mail-touchlock
sudo chmod 2755 /usr/bin/mail-lock

Since all you ran was chmod 777 -R /usr/bin and there are no sub directories in that directory, all the files except for the links and the obvious ones above in the list with the "suid" permission set on them, the rest of the files in that directory have permission settings of -rwxr-xr-x (or 755). You could reset those permissions to those files without touching the setuid files or the links by typing in:

sudo chmod go-w /usr/bin/*

that will set the group and other permissions to r-x and leave the links alone as lrwxrwxrwx. DO NOT RUN AS chmod 755 as that will mess up the permissions we have fixed!

Terrance
  • 41,612
  • 7
  • 124
  • 183
  • Live USB fine too? – Josh Pinto Jun 09 '15 at 03:49
  • @BrentonHorne That should be fine. – Terrance Jun 09 '15 at 03:50
  • To be clear this shouldn't lead to any data loss? I have a mediawiki installation on my PC (via LAMP) and I would sure hate to loose it. I don't really have much in the way of external hard drives to back my PC up. – Josh Pinto Jun 09 '15 at 03:51
  • @BrentonHorne No, as long as you don't delete anything, you should be fine. The files just need to be set from -rwxrwxrwx to -rwsr-xr-x. The s means "sticky bit" and is used for apps that need root like sudo etc. – Terrance Jun 09 '15 at 03:52
  • This is not the sticky bit, this is the setuid bit. Sticky bit has no effect on non-directories, and its letter in chmod is "t". "s" is the setuid bit. – thomasrutter Jun 09 '15 at 04:29
  • @thomasrutter I have heard it either way. But thank you for the explanation. – Terrance Jun 09 '15 at 04:31
  • @thomasrutter and changed in answer. :-) – Terrance Jun 09 '15 at 04:36
  • 1
    Well I'll be damned, it worked and it wasn't anywhere near as tedious as I thought it'd be. So for those that encounter this problem in the future, follow this answer it works perfectly, with no data loss. Oh, although I should add no lppasswd file was detected when I was on the live USB. – Josh Pinto Jun 09 '15 at 05:30
  • @BrentonHorne I am so glad that it worked for you! :-) That missing file might be only what was on my system when I ran for all files that needed the "suid" on it. No biggie. But I am very happy for you! – Terrance Jun 09 '15 at 05:32
  • This is a good answer for patching the thing and be able to do a backup. But I still recommend a reinstall after that; running a system will all permissions messed up will create problems in the future. Backup, reinstall, and learn to edit sudoers to give you permission instead of these savages chmods.... – Rmano Jun 09 '15 at 08:20
2

I think the only appropriate answer is to re-install your system. Otherwise you will forever be discovering things that don't work as they should.

You should recover any important files you need from it first, back them up, and then re-install.

Never run a far-reaching chmod -R over system files. There are just too many things that absolutely require permissions to be set a certain way, that will break if they are set to something else, even say, 777.

This includes many executables that require "setuid" as stated in the other answer. But it also includes applications and services that check to make sure that their file permissions are set up securely and refuse to run if they are insecure. This is common of network daemons, for example.

There is so far no easy way to tell Ubuntu/Debian to restore all file permissions to their factory settings. It would be a messy manual process to start repairing them one-by-one. If you just went back and fixed the things that were actually broken, you're still left with a horribly insecure system, especially if it is on a network and is running any servers.

thomasrutter
  • 36,774