The sudoers Mistake Everyone Makes Once

You locked yourself out of sudo. You edited /etc/sudoers with vim. You made a syntax error. You saved and quit. Now you can’t run sudo to fix it, and your only way back is a reboot with a live USB.

I’ve been there. I’ve fixed servers at 2 AM where someone did exactly this. Here’s the thing: the tool to edit sudoers exists for a reason, and you’re not using it.

Never Touch /etc/sudoers Directly

This is the rule. There are no exceptions.

# WRONG
$ sudo vim /etc/sudoers

One syntax error, one typo, one missed colon, and you’ve created an unrecoverable mess. The file is still there, but it’s broken, and sudo won’t trust it anymore. You’ll get errors like:

sudo: parse error in /etc/sudoers near line 42
sudo: no valid sudoers sources found, quitting

You’re now locked out. Congratulations.

Use visudo (The Safe Way)

visudo is a wrapper that edits sudoers safely:

1. Opens the file in a text editor
2. Checks syntax before saving
3. Creates a temporary copy so you can’t corrupt the original
4. Only writes back if syntax is valid

$ sudo visudo

It opens with your $EDITOR (usually nano or vim). Edit. Save. If there’s a syntax error, it asks if you want to fix it or discard changes. If syntax is good, it writes and you’re done.

This one command prevents 90% of sudoers disasters.

Understanding sudoers Syntax

Here’s the format:

user host=(runuser:rungroup) [NOPASSWD:] command

Examples:

# Allow 'alice' to run anything as root, requires password
alice ALL=(ALL:ALL) ALL

# Allow 'bob' to run /bin/systemctl as root, no password
bob ALL=(ALL:ALL) NOPASSWD: /bin/systemctl

# Allow 'ops' group to run docker commands, no password
%ops ALL=(ALL:ALL) NOPASSWD: /usr/bin/docker

# Allow 'deploy' to restart nginx only, as www-data user
deploy ALL=(www-data:www-data) /usr/sbin/nginx -s reload

Key parts:

• user — username (or %groupname for groups)
• host — which machines (usually ALL)
• (ALL:ALL) — run as which user:group (ALL:ALL means root:root)
• NOPASSWD: — optional, don’t ask for password
• command — which command(s) to allow (absolute path)

Common Mistakes

1. Forgetting the colon:

# WRONG
alice ALL ALL /usr/bin/systemctl

# CORRECT
alice ALL=(ALL:ALL) /usr/bin/systemctl

2. NOPASSWD placement:

# WRONG
alice ALL NOPASSWD: (ALL:ALL) /usr/bin/systemctl

# CORRECT
alice ALL=(ALL:ALL) NOPASSWD: /usr/bin/systemctl

3. Using unquoted wildcards:

# Dangerous - allows ANY command starting with docker
alice ALL=(ALL:ALL) /usr/bin/docker*

# Better - list specific commands
alice ALL=(ALL:ALL) /usr/bin/docker ps, /usr/bin/docker start, /usr/bin/docker stop

4. The too-permissive entry:

# VERY BAD - allows running anything with sudo
alice ALL=(ALL:ALL) ALL

This is sometimes necessary (dev team, ops users), but be explicit about it.

Check Your Own Permissions

See what you’re actually allowed to run:

$ sudo -l

Output:

User kingpin may run the following commands on localhost:
    (root) NOPASSWD: /usr/sbin/systemctl
    (www-data) /usr/local/bin/backup.sh
    (ALL) /usr/bin/docker

This tells you:

• Run systemctl as root without a password
• Run backup.sh as www-data (will prompt for password)
• Run docker as any user (will prompt for password)

If you don’t see a command, you can’t run it.

Group-Based Access

Instead of listing users, use groups:

# All users in the 'docker' group can run docker
%docker ALL=(ALL:ALL) NOPASSWD: /usr/bin/docker

# All users in the 'ops' group can reload services
%ops ALL=(ALL:ALL) NOPASSWD: /usr/sbin/systemctl reload-or-restart

Then add users to groups:

$ sudo usermod -aG docker alice
$ sudo usermod -aG ops bob

Groups are cleaner than listing individual users. When someone leaves, remove them from the group, not from sudoers.

The NOPASSWD Danger

NOPASSWD is convenient but risky. If someone compromises that user account, they can run commands as root without entering a password.

Use it for:

• Service accounts that need to run automation
• Commands that are read-only or low-risk (showing logs, restarting services)

Don’t use it for:

• Commands that modify files
• Commands that delete or backup data
• Anything you don’t fully trust

Better yet, use NOPASSWD with specific, limited commands only.

Sudoers Include Pattern

For large setups, split sudoers into multiple files:

# Include specific rule files
#includedir /etc/sudoers.d

Then create separate files:

$ sudo visudo -f /etc/sudoers.d/ops
$ sudo visudo -f /etc/sudoers.d/docker
$ sudo visudo -f /etc/sudoers.d/deploy

Each file is validated independently. One broken file doesn’t lock out everyone.

The Recovery (If You Broke It)

If you edited sudoers directly and now you’re locked out:

Option 1: Reboot and fix with live USB

# Boot live USB, mount root filesystem
$ sudo mount /dev/sda1 /mnt
$ sudo nano /mnt/etc/sudoers
# Fix the error, save
$ sudo umount /mnt
# Reboot

Option 2: Use another admin If another user with sudo access is logged in, they can fix it for you.

Option 3: Boot into single-user mode On some systems, you can boot directly to a root shell.

All painful. Don’t let this happen.

The One Thing

Right now:

$ sudo visudo

Get familiar with the tool. Check your current rules. Make sure they’re correct. Then use visudo for any future edits. That’s it. That’s your insurance policy.