1

I'm running CentOS7 on an old dell box that I repurposed as a home server. I also ssh into it from a remote location to make sure everything is running smoothly, and to do things like rsync my laptop. In other terms, nobody is usually at home to reset the machine if anything goes wrong.

The situation:

Sometime last week, I must have broken something that allows commands like sudo, su, and pkexec to work.

Su won’t accept my root password, sudo gives the error:

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

I tried running something like pkexec /bin/bash, but I got the error:

pkexec must be setuid root

seeing that, I then did:

[crlsmdrn@server ~]$ ls -l /usr/bin/sudo                                                                                                       

---x--x--x. 1 root root 143248 Jun 27 13:03 /usr/bin/sudo

So, is there any way to set permissions back to 4755 on sudo so I can get a root shell back remotely without having to reboot the machine?

Thanks

  • Looks like permissions are broken. You can not fix this without root access. Boot to recovery mode and see google.com/amp/s/www.cyberciti.biz/tips/… – Panther Dec 7 '18 at 0:27
  • A reboot won't fix those permissions. A reboot, boot of a rescue disk and changing the perms back to what they were will. – tink Dec 7 '18 at 0:28
  • It sounds as if you have recursively removed permissions as both sudo and pkexec have had their extra permissions revoked. If your disks are not too big, you could search the entire system to see if there are and suid programs left which might give you a way into the system. Use find / -perm +2000 -type f -ls and add the output to the question. – icarus Dec 7 '18 at 1:25
  • You were right; it looks like I did accidentally. – Carlos1001 Dec 7 '18 at 2:16
0

I was able to reset permissions on sudo without rebooting into rescue mode! This is what I did:

Thankfully, systemd was still allowing me to restart daemons because it was authenticating via polkit.

So, I made a unit file in my home directory containing:

/home/crlsmdrn/sudo-reset.service:

[Unit]
Description=reset sudo

[Service]
Type=oneshot
ExecStart=/home/crlsmdrn/sudo-reset.sh

[Install]
WantedBy=multi-user.target

I then made a file named sudo-reset.sh.

/home/crlsmdrn/sudo-reset.sh:

#!/bin/sh
chmod 4755 /usr/bin/sudo

Then:

[crlsmdrn@server ~]$ chmod +x /home/crlsmdrn/sudo-reset.sh

Followed by enabling and running the service:

[crlsmdrn@server ~]$ systemctl enable /home/crlsmdrn/sudo-reset.service
[crlsmdrn@server ~]$ systemctl start sudo-reset-service

[crlsmdrn@server ~]$ sudo
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-u user] [VAR=value] [-i|-s]
            [<command>]
usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-u user] file ...

I then was able to do sudo -s, then see what permissions were broken by looking back at the bash history; it looks like only /usr/bin got borked, so I ran rpm --setperms -a, which appeared to fix the permissions.

Don't forget to disable the service after doing this.

Moral of the story here: never run chown -R root:root on /usr/bin without expecting things to work the same.

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.