When you let someone edit a root owned file with sudo, give them sudoedit, not permission to run an editor. A privileged editor can open a shell, which skips sudo's controls and logs. sudoedit works on temporary copies owned by the user, and only the copy back is privileged.
The problem with sudo vim
The sudoers manual says that once sudo executes a program, the program is free to do whatever it likes, including starting other programs. Editors, pagers, mail programs and terminal programs commonly allow shell escapes. If a rule allows /usr/bin/vim /etc/hosts, the editor can usually be told to run a shell, and that shell is root. Sudo's access control and logging are bypassed.
The manual lists restricting such programs as one answer, and says sudoedit is a better solution for running editors via sudo.
How sudoedit is specified
sudoedit is a built-in command in the sudoers file. The manual says it is built into sudo itself and must be written as sudoedit, not a full path. If you write /usr/bin/sudoedit, the name is silently converted, and a fully qualified path for sudoedit is treated as an error by visudo. A rule looks like this:
%webadmins ALL = sudoedit /etc/nginx/conf.d/*.conf
The manual gives an example that uses a regular expression to limit paths:
bob ALL = sudoedit ^/etc/(motd|issue|hosts)$
Anchored expressions avoid the wildcard problem described in the argument wildcard post. Users then run sudoedit /etc/hosts, or sudo -e /etc/hosts.
Symlink protections
Editing as root through a path someone else can influence is dangerous, so sudoedit has defenses:
- By default it does not follow symbolic links when opening files. The
sudoedit_followflag, or theFOLLOWtag per command, relaxes this. sudoedit_checkdir, on by default, checks each directory in the path for writability by the invoking user. It refuses to follow symlinks in writable directories and refuses to edit a file located in a writable directory. These checks are not enforced when root runs sudoedit.
Keep both defaults. If a legitimate file lives in a user writable directory, move the file instead of weakening the check.
Remaining caveats
- The sudo manual says the editor is chosen from
SUDO_EDITOR,VISUALandEDITOR, in that order, falling back to the sudoerseditoroption. Users pick their own editor, which is fine because it runs as them, but you can limit the choice with theeditoroption if you want. - Granting sudoedit on a sensitive file such as
/etc/sudoersor/etc/shadowis still granting control of the system. Choose files with care. - Sudoedit does not help if the user already has broader rules. Review all rules for the account.
The manual's other approach, the NOEXEC tag, can stop dynamically linked programs from running further commands, but only where the system supports it, so test it.
Safeguard offers compliance evidence automation for access reviews, and a free scan at gold.safeguard.sh/scan.
Quick check
Why is sudoedit safer than sudo vim?
The sudo manual says temporary copies are made with the invoking user as owner, and the editor runs on those copies. A shell escape from the editor does not give root. Only the copy back to the real file is privileged.
Does sudoedit follow symbolic links?
Not by default. The sudoedit_follow flag or the FOLLOW tag changes that, and sudoedit_checkdir adds directory writability checks.
Sources
- sudoers(5) manual page, man7.org, sudoedit, tags and security notes
- sudo(8) manual page, Debian manpages, the -e option
Last reviewed: 19 October 2026.
