How did this usage of chmod break sudo access?

The Mechanism of Failure

Sudo relies on the setuid (set user ID) permission bit to function correctly. When you run sudo, the operating system must temporarily elevate your current user account to the root account. This elevation is achieved through the setuid mechanism, which tells the kernel to run the program with the file owner's permissions rather than the invoking user's permissions.

For this to work, the file must have specific permissions. The standard permission for /usr/bin/sudo is typically 4755. The leading 4 indicates the setuid bit is set. The 7 means the owner (root) has read, write, and execute rights. The 55 means the group and others have read and execute rights, but no write access.

When you apply a command like chmod 777 /usr/bin/sudo, you are granting write access to everyone. Modern Linux kernels consider any setuid binary that is writable by anyone other than the owner to be a significant security vulnerability. An attacker could potentially modify the binary to gain permanent root access if they had write permissions. Therefore, the kernel silently disables the setuid behavior for that file. The next time you type sudo ls, the system runs the ls command using your regular user privileges, effectively making it appear as though sudo is broken or asking for a password without elevating rights.

Diagnosing the Issue

If you suspect you have accidentally changed the permissions of a critical system file, you can verify the current state by checking the permissions of the sudo binary. Open your terminal and run the following command:

ls -l /usr/bin/sudo

You should see output similar to this:

-rwsr-xr-x 1 root root ... /usr/bin/sudo

The s in the owner execute position confirms the setuid bit is active. If you see an x instead of an s, or if the group/other sections show a w (write permission), the setuid functionality has been compromised. For example, -rwxrwxrwx indicates that all permissions are open, which will definitely break sudo.

Another symptom is that sudo might still prompt for a password, but upon entering it, the command fails with "permission denied" errors for operations that should be allowed as root. This happens because the process is running as your limited user, not as root.

Restoring Correct Permissions

To fix this issue, you need to restore the correct ownership and permission bits. Since you likely cannot use sudo to fix itself, you may need to log in as the root user directly via a TTY console (Ctrl+Alt+F3) or use a live USB environment if you are completely locked out. Assuming you have root access via another method, execute the following steps:

1. Reset Ownership: Ensure the file is owned by root.

   chown root:root /usr/bin/sudo

2. Set Correct Permissions: Apply the standard secure permissions.

   chmod 4755 /usr/bin/sudo

The 4755 mode sets the setuid bit (4) and grants read/write/execute to root (7) and read/execute to group/others (55). After running these commands, test the restoration by typing sudo whoami. It should return root.

Preventing Future Incidents

Avoid using broad permission changes like chmod 777 on system directories or binaries. Instead, target specific users or groups where necessary. If you need to allow a specific user to run certain commands without full sudo access, refer to our guide on Understanding sudoers File: Allowing Execution of Specific Commands for a User. This provides granular control without compromising the integrity of core system binaries.

Additionally, always double-check the path when using chmod. A common mistake is running chmod 777 ~ which opens your home directory, but accidentally running chmod 777 /usr or similar can cascade into breaking multiple system tools. For more context on how sudo handles file permissions generally, see Understanding Sudo File Permissions and Access to 'file.txt'.

Recovering from Other Broken Binaries

If you broke other binaries besides sudo, the same principle applies. Check the default permissions for those files. You can often find the original permissions by reinstalling the package that owns the file. For example, on Debian-based systems, you can run dpkg --verify /usr/bin/sudo to check for corruption, or reinstall the package with apt-get install --reinstall sudo to reset permissions automatically.

Frequently Asked Questions

Why does sudo ask for my password but still fail?

This occurs because the authentication module (PAM) still works even if the setuid bit is disabled. The system verifies your password against the shadow database, but since the binary lacks the setuid bit, it executes with your user privileges after authentication, leading to permission denied errors for root tasks.

Can I use chattr to fix this?

No, chattr modifies extended attributes like immutable flags, not standard Unix permissions. While setting the immutable flag can protect files from being modified, it does not restore the setuid bit if it was cleared by a chmod command. You must use chmod to adjust the permission bits.

What if I changed permissions on /bin/bash?

If you made /bin/bash group-writable, interactive shells spawned by that binary may also lose setuid capabilities if they were intended to be setuid. However, bash itself is rarely setuid. The primary risk is that scripts relying on specific execution environments might behave unpredictably. Restore permissions with chmod 755 /bin/bash.

How do I check if other binaries are broken?

You can scan for setuid binaries that are world-writable by running find / -perm -4002 -type f 2>/dev/null. This searches for files with the setuid bit and group-write permission. Any results found should be corrected immediately to maintain system security.

Is there a safe way to give a user admin rights?

Yes, adding a user to the sudo group is the standard method. Use usermod -aG sudo username on Debian/Ubuntu or usermod -aG wheel username on RHEL/CentOS. This grants sudo access via the sudoers configuration without altering binary permissions.