The sudoers file controls which users can run commands with elevated privileges on Linux systems. Located at /etc/sudoers, this configuration file determines who gets administrative access and what they can do with it. Edit this file incorrectly and you lock yourself out of admin rights completely.
This guide shows you how to modify the sudoers file safely using the visudo command, grant privileges to users, create custom access rules, and recover from configuration mistakes.
What Is the sudoers File?
The sudoers file lives at /etc/sudoers on most Linux distributions. When someone runs the sudo command, the system checks this file first. Only users listed here can execute commands with root privileges.
Think of it as a gatekeeper. Regular users cannot perform system administration tasks without proper entries in this file. System administrators use the sudoers file to balance security with necessary access.
File Structure
The sudoers file contains three main components:
| Component | Purpose | Example |
|---|---|---|
| Comments | Lines the system ignores | Lines starting with # |
| Aliases | Groups of users, hosts, or commands | User_Alias ADMINS = tom, jane |
| Rules | Permission specifications | tom ALL=(ALL) ALL |
A typical permission entry follows this pattern:
username hostname=(target_user) allowed_commandsGranting full administrative rights looks like this:
sarah ALL=(ALL) ALLHere, sarah can run any command as any user on any machine.
How To Edit the sudoers File Safely
Never open /etc/sudoers with a regular text editor. Use the visudo command instead:
$ sudo visudoThe visudo utility opens the file in your default editor and checks for mistakes when you save. If errors exist, it refuses to save and shows you what went wrong.
Changing Your Editor
By default, visudo opens the file in vi or nano depending on your distribution. Change this preference:
$ export EDITOR=nano
$ sudo visudoThis sets nano as your editor for the current session. Make it permanent by adding the export line to your ~/.bashrc file.
Granting User Privileges
The most common task involves giving a user general administrative access. Systems configured with an admin group make this easy.
Using Groups
On Ubuntu, add users to the sudo group:
$ sudo usermod -aG sudo usernameOn CentOS and RHEL, use the wheel group:
$ sudo usermod -aG wheel usernameEvery member of these groups gains full administrative capabilities. This approach simplifies management when multiple users need the same level of access.
Individual User Access
Grant rights to specific users by editing the sudoers file directly:
$ sudo visudoAdd this line:
mike ALL=(ALL) ALLMike now has complete administrative access on all systems.
Creating Custom Rules
Sometimes users need limited access rather than full privileges. Restrict them to specific commands.
Limiting Commands
Allow a user to update packages but nothing else:
mike ALL=(ALL) /usr/bin/apt-get update, /usr/bin/apt-get upgradeMike can only run these two commands with sudo. All other attempts fail.
Using Aliases
Organize rules with aliases when managing multiple users or commands:
User_Alias DEVTEAM = alice, bob, charlie
Cmnd_Alias RESTART = /bin/systemctl restart nginx, /bin/systemctl restart apache2
DEVTEAM ALL=(ALL) RESTARTThe development team can restart web servers but cannot perform other admin tasks.
Passwordless Commands
Remove the password requirement for low-risk operations:
mike ALL=(ALL) NOPASSWD: /usr/bin/updatedbMike runs updatedb without entering a password. Use this feature sparingly and only for safe commands.
Troubleshooting Common Issues
| Problem | Cause | Solution |
|---|---|---|
| User not in sudoers file | Missing group membership | Add user to sudo or wheel group |
| Parse error | Syntax mistake | Run visudo and fix the indicated line |
| Command not allowed | Incorrect path or rule | Verify command path with which |
| Changes not working | User still logged in | Log out and back in |
Emergency Recovery
If the sudoers file becomes corrupted and locks you out, boot into single-user mode:
- Reboot the system and enter recovery mode at the boot menu
- Mount the root filesystem as read-write
- Run visudo to fix the configuration
- Reboot normally
# mount -o remount,rw /
# visudoSecurity Best Practices
Follow these guidelines to keep your system protected:
Review the sudoers file monthly. Remove outdated entries promptly. Users who leave your organization or change roles no longer need their previous access levels.
Grant minimal access. Users should receive only necessary permissions. A database administrator needs database tools, not network configuration rights.
Enable activity tracking by configuring sudo to log all privileged command usage:
Defaults logfile="/var/log/sudo.log"This records every sudo invocation with timestamps and user information. Check these logs regularly for unusual activity.
Maintain console access. If the sudoers file breaks, you need alternative paths to fix it. Keep the root password available through secure channels.
/var/log/auth.log or /var/log/secure by default.
Using sudoers.d Directory
Instead of editing the main sudoers file, create separate configuration files in /etc/sudoers.d/:
$ sudo visudo -f /etc/sudoers.d/database-teamThis approach offers several benefits. Package updates will not overwrite your custom rules. If a configuration file causes problems, you can remove it without touching the main file. Multiple administrators can work on different rule sets without conflicts.
Files in this directory must not contain periods or end with tildes. Name them clearly to indicate their purpose, like webserver-admins or backup-operators.
FAQs
The visudo command prevents saving files with syntax errors. It shows the line number and error type, letting you fix mistakes before they break sudo access.
You can, but you should not. Direct editing with nano or vim risks creating syntax errors that lock you out. Always use visudo for safety.
Run sudo -l to list all sudoers rules that apply to your current user account. This shows exactly what you can do with sudo.
Changes apply to new login sessions. Users must log out and back in for group membership changes to activate. Existing sessions use old permissions.
Most systems log to /var/log/auth.log on Debian/Ubuntu or /var/log/secure on RHEL/CentOS. You can configure a custom log file location in the sudoers file.
