sudo: must be setuid root! I need to change the ownership of /usr/bin to root

[michel]

Greetings,

Just finished re-installing 12.04 32 bit to 64. Everything was running fine until I decided to change the ownership of /usr/bin to current user (I was trying to copy an application folder to /usr/bin) anyway I now get the following message every time I try using sudo or running synaptic or other root applications:

sudo: must be setuid root

Is there a way to change the ownership without having to re-install? I tried using the root actions in Dolphin but it does not work.

Michel

[james147]

Everything was running fine until I decided to change the ownership of /usr/bin to current userl

Consider this your lesson learned: NEVER change the permissions of system folders away from root*.

It will just cause all sorts of errors like these and makes your system more vulnerable to scripts trashing/taking over your system.

chown -R root:root /usr/bin

Might work from the system, but you might need to do it from a live cd.

If you need to install an application manually I would suggest installing it to /usr/local/bin, that is where admin maintained programs are meant to go, /usr/bin is meant to be for programs managed by the package manager (this makes it easier to find and remove applications you have installed your self and means the package manager wont come across files it doesn't know about). And you should use

sudo cp /path/to/script /usr/local/bin/

when you want to install them or if you must use a gui, run

kdesudo dolphin

but be careful when you do this as you can quite easily trash your system by accident.

* Unless you really, really know what you are doing

[michel]

Thanks James,

I managed to change the ownership of /usr/bin back to root but I'm still unable to use sudo. I still get the same

sudo: must be setuid root

message. Synaptic will not run either.

Michel

[michel]

I booted back with the live CD and gave the following command

chmod 4755 /usr/bin/sudo

now sudo is working and synaptic is launching.

1- Should I run the chmod command recursively on /usr/bin/? would that be the correct command:

chmod -R 4755 /usr/bin

?
2- Can I consider it a case closed or should I re-install to avoid future potential problems?

Michel

[james147]

Should I run the chmod command recursively on /usr/bin/?l

NO... do NOT do this

sudo needs the stickybit set so that it can launch as root, by setting it on every executable you give everything the ability to run as root.

There are afew programs that need it to work, but most should not have it.

The best thing I can suggest is to reinstall the packages now to fix any other potential problems.

But you might consider a reinstall if you want to be absolutely sure.

I also think you should take this experience and learn what commands actually do before trying to run them to avoid such problems in the future. And if you are still not sure, feel free to come back here for more advice.

[michel]

Thanks a lot James.

What packages are you talking about?

As far as lessons learned, yes I agree but I really think the lack of root login is responsible, in my opinion, for more problems because you end up trying to change permissions when you run into access issues. In Mepis we can choose to log in as root, do the work and then log out. I truly beleive sudo is more conductive to problems.

Michel

[kubicle]

Consider this your lesson learned: NEVER change the permissions of system folders away from root*.

chown -R root:root /usr/bin

While that will improve things, it's not a perfect solution since not everything in /usr/bin is supposed to be owned by root:root. A few things in there have different UID and/or GID (another reason not to run chmod/chown recursively on system directories)

[michel]

I reinstalled to make sure. Thank you all.

Michel

[vinnywright]

if it helps hear is a list of the permissions of the things in /usr/bin that are not root:root ,,,,,,,,,

"at" is daemon daemon , "bsd-write" is root tty , "chage" is root shadow , "crontab" is root crontab , "dotlockfile" is root mail , "expiry" is root shadow , "kppp" is root dialout , "ksplasherx" is vinny vinny , "lppasswd" is root lpadmin , "mail-lock" "mail-touchlock"& "mail-unlock" is root mail , "mlocate" is root mlocate , "ssh-agent" is root ssh , "wall" is root tty , this list is how it is @hear

VINNY

oops guess you reinstalled wile I was geting this list together for ya ,,,,,,,,O well

[kubicle]

if it helps hear is a list of the permissions of the things in /usr/bin that are not root:root ,,,,,,,,,
oops guess you reinstalled wile I was geting this list together for ya ,,,,,,,,O well

Probably safer to reinstall, as your (or anyone else's) list is unlikely to be exhaustive (as it depends on what is installed). Doubly so if permissions were also changed recursively.

PERM       UID    GID     FILE
-rwxr-sr-x root   ssh     /usr/bin/ssh-agent
-rwxr-sr-x root   tty     /usr/bin/bsd-write
-rwxr-sr-x root   mail    /usr/bin/mail-touchlock
-rwxr-sr-x root   shadow  /usr/bin/expiry
-rwsr-sr-x daemon daemon  /usr/bin/at
-rwxr-sr-x root   mlocate /usr/bin/mlocate
-rwxr-sr-x root   shadow  /usr/bin/chage
-rwxr-sr-x root   mail    /usr/bin/mail-lock
-rwxr-sr-x root   crontab /usr/bin/crontab
-rwxr-sr-x root   utmp    /usr/bin/screen
-rwxr-sr-x root   mail    /usr/bin/dotlockfile
-rwxr-sr-x root   mail    /usr/bin/mail-unlock
-rwxr-sr-x root   tty     /usr/bin/wall
-rwsr-xr-x root   lpadmin /usr/bin/lppasswd

[james147]

As far as lessons learned, yes I agree but I really think the lack of root login is responsible, in my opinion, for more problems because you end up trying to change permissions when you run into access issues. In Mepis we can choose to log in as root, do the work and then log out. I truly beleive sudo is more conductive to problems.

Improper use of it yes like the improper use of a root login can cause all sorts of problems, but it alone is not responsible for your troubles. There is nothing you cannot do with sudo that you can with a full root login. There is no need to change the permissions of anything or do a full login as root when you can launch any gui application you need to with

kdesudo gui-application

to run it as if you had login as root.

[claydoh]

Thanks a lot James.

What packages are you talking about?

As far as lessons learned, yes I agree but I really think the lack of root login is responsible, in my opinion, for more problems because you end up trying to change permissions when you run into access issues. In Mepis we can choose to log in as root, do the work and then log out. I truly beleive sudo is more conductive to problems.

Michel

I do beg do differ on that. It is simply different, not really better or worse. There is nothing you need to do that sudo cannot do. Using sudo you don't have to log out/log in as root/do a task/ log out. Actually using su in a root-style system you don't need to log out either, really. If sudo were really prone to problems, then all the various distros that use it, both Ubuntu-based and not, must be doing something wrong all these years Do not get me wrong, I am not saying one way is better than the other. Most of us who came to use a *buntu from another distro at one time or another have questioned the sudo issue, perhaps even enabled root (Like me, in 2005). Then one day, usually fairly quickly, we all decide to give sudo the benefit of the doubt and realize it was all much ado about nothing.

[kubicle]

A good rule of thumb is that "if you wouldn't do it when logged in as root, don't do it with sudo either"

[michel]

@Vinny It was too complicated anyway. But thanks!

I understand the pros and cons. I just miss the ability to use su. Let's see if sudo grows on me. There is also the feeling that you are TOTALLY in controll. If it's MY system, then I should have the option of tranforming myself into a super user :-)

Michel

[james147]

@Vinny It was too complicated anyway. But thanks!

I understand the pros and cons. I just miss the ability to use su. Let's see if sudo grows on me. There is also the feeling that you are TOTALLY in controll. If it's MY system, then I should have the option of tranforming myself into a super user :-)

Michel

sudo -i

sudo -s

man sudo

There truly is no limit to it.