The Sudoers File: Edit It With visudo or Lock Yourself Out

The sudoers file controls who can run what as another user, and it has a property that makes it unlike almost any other config file on a Linux system: a syntax error in it can lock every account out of administrative access, including yours, immediately and permanently.

That is why visudo exists, and why the advice to always use it is repeated so insistently. This post covers what the file actually contains, the modern drop-in approach that makes edits much safer, and — since you may be reading this having already broken it — how to recover from a system where sudo no longer works.

Why visudo, specifically
Reading the syntax
Use sudoers.d, not the main file
Granting narrowly, and the ways narrow grants leak
Recovering when sudo is already broken
How this fits the rest of the stack
FAQ

Why visudo, specifically

visudo does three things that opening the file in an editor does not.

It validates before saving. On exit it parses the file, and if the syntax is wrong it refuses to install it, offering to re-edit. This is the whole point: a broken sudoers file never reaches disk.
It locks against concurrent edits. Two administrators editing simultaneously would otherwise silently overwrite each other.
It edits a temporary copy and moves it into place atomically. So an interrupted edit — a dropped connection, a killed terminal — leaves the original intact rather than a truncated file.

The failure it prevents is total. sudo reads the file on every invocation, and if it cannot parse it, it refuses to run anything. There is no partial mode and no fallback. On a system where root has no password — the default on Ubuntu and many cloud images — losing sudo means losing administrative access entirely.

You can choose the editor: EDITOR=nano visudo, or set it permanently with update-alternatives --config editor on Debian-family systems. Use whatever you like; just go through visudo.

You can also validate a file without editing it, which is useful in configuration management: visudo -c checks the main file, and visudo -cf /path/to/file checks a specific one. Any automated process that writes sudoers rules should run this check before the file goes live.

Reading the syntax

The core rule format is consistent and once you can read one line you can read them all.

user  host = (runas_user:runas_group)  NOPASSWD: commands

# Examples:
root     ALL=(ALL:ALL) ALL
%sudo    ALL=(ALL:ALL) ALL
%wheel   ALL=(ALL)     ALL
deploy   ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

Reading the fields left to right:

user — a username, or a group prefixed with %. Group-based rules are what you almost always want, because adding someone to a group is a smaller and more auditable action than editing sudoers.
host — which machines the rule applies to. ALL on a per-machine file, and meaningful only if you distribute one sudoers file across many hosts.
(runas_user:runas_group) — who the command may be run as. (ALL:ALL) means any user and group; (root) restricts to root.
NOPASSWD: — optional, skips the password prompt for the commands that follow.
commands — absolute paths, comma-separated, or ALL.

Two details that bite people. Rules are evaluated in order and the last match wins, so a broad grant later in the file silently overrides a narrow restriction earlier. And commands must be absolute paths — a bare systemctl matches nothing, because a relative path would let a user place their own binary earlier in PATH.

Use sudoers.d, not the main file

Modern sudoers includes a line at the end reading @includedir /etc/sudoers.d (older syntax: #includedir, where the # is part of the directive rather than a comment, which confuses everyone once). Files placed in that directory are read as if appended.

This is strictly better than editing the main file:

Each grant is a separate small file that can be added and removed independently.
Configuration management can write one file per concern without templating the whole of sudoers.
A mistake affects one file, and removing that file — which you can do from a rescue shell — restores working sudo.
Package upgrades do not conflict with your edits.

Create them with visudo -f /etc/sudoers.d/deploy-restart, which validates the individual file. Filenames must not contain a dot or end in ~, or they are silently ignored — a genuinely irritating failure mode where your rule simply does nothing with no error anywhere.

Permissions matter too: files must be 0440 and owned by root. Anything more permissive and sudo refuses to read the file, which is a safety feature rather than a bug.

Granting narrowly, and the ways narrow grants leak

The instinct when someone needs to restart a service is to grant ALL. The better habit is to grant exactly the command, and to understand where that still leaks.

# Good: one specific action
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

# Leaky: the wildcard permits `systemctl restart anything`,
# and on many systems also `systemctl -H other.host ...`
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart *

# Dangerous: an editor is a shell escape
ops ALL=(root) NOPASSWD: /usr/bin/vim

The general principle is that a narrow grant is only as narrow as the command allows. A great many programs can be persuaded to run arbitrary code:

Editors — vim, nano, less, more — all offer a way to spawn a shell or run a command from inside.
Interpreters — python, perl, awk, find -exec — are obviously arbitrary code execution.
Anything that takes a config file path, since the config may specify commands to run.
Anything with a plugin or hook mechanism.

So granting sudo vim /etc/nginx/nginx.conf is functionally granting root. If someone needs to edit a file as root, use sudoedit (or sudo -e), which copies the file to a temporary location, opens it as the invoking user, and copies it back — the editor never runs with elevated privileges.

And avoid negation rules like ALL, !/bin/su. They look like a restriction and are trivially bypassed by invoking the command through a different path or a copy of the binary. Allowlist, never blocklist.

Recovering when sudo is already broken

If you are here because sudo now says the file is malformed, there is a path back. It depends on what access you still have.

Keep any existing root shell open. If you have a terminal where you are already root, do not close it — fix the file from there with visudo. This is why the standing advice is to keep a second session open while editing sudoers.
If root has a password, su - and fix it.
On a physical or console-accessible machine, reboot into single-user or recovery mode from the bootloader, remount the filesystem read-write, and repair the file.
On a cloud instance, use the provider’s console or rescue mode: boot a rescue environment, mount the instance’s disk, and either fix the syntax or delete the offending file from /etc/sudoers.d/.
As a last resort, detach the disk, attach it to a working instance, mount it, repair, and reattach.

The recovery is much simpler if the mistake was in a drop-in file, because deleting one file from /etc/sudoers.d/ restores working sudo without needing to reconstruct correct syntax under pressure. That is a large part of why drop-ins are worth the habit.

The habit that prevents all of this: open a second terminal, confirm sudo works in it, then edit in the first. If the edit breaks something, the second session is your way back in — and it costs nothing to establish.

How this fits the rest of the stack

Sudo policy, recovery access and console procedures are the kind of work that comes with operating servers directly — real and necessary, and entirely absent from the invoice until an outage. The RunxBuild hosting calculator covers the costs that do appear: the service, the database, the storage and the bandwidth. On RunxBuild the deploy target is managed rather than a machine you hold root on — services deploy from a repository with logs, environment variables and one-action rollback, which removes this class of lockout from the deployment path entirely.

Useful related references:

FAQ

Why should I use visudo instead of editing /etc/sudoers directly?

Because visudo validates the syntax before saving and refuses to install a broken file. A malformed sudoers file makes sudo refuse to run anything at all, and on systems where root has no password — the default on Ubuntu and most cloud images — that means losing administrative access entirely.

What is /etc/sudoers.d for?

Drop-in files read as if appended to the main sudoers file. Each grant becomes a separate small file that can be added or removed independently, which makes configuration management cleaner and recovery much easier — deleting one file restores working sudo. Create them with visudo -f so they are validated.

Why is my file in sudoers.d being ignored?

Filenames containing a dot or ending in a tilde are silently skipped, with no error anywhere. Permissions also matter: the file must be mode 0440 and owned by root, or sudo refuses to read it.

Is it safe to grant sudo access to a text editor?

No. Editors including vim, nano, less and more all provide a way to spawn a shell or run commands from inside, so granting sudo on an editor is effectively granting full root. Use sudoedit (sudo -e) instead, which opens a temporary copy as the invoking user and copies it back.

How do I fix a broken sudoers file if sudo no longer works?

Use an existing root shell if you have one open, or su if root has a password. Otherwise boot into recovery or single-user mode, or use your cloud provider’s rescue mode to mount the disk and repair it. If the mistake was in a drop-in file, deleting that one file is enough — which is a good reason to use them.