sudoers checker

Paste your sudoers rules and see, in plain English, who can run what as whom, which rules quietly hand out a root shell, and which settings let a user load their own code into root commands.

Runs in your browser. What you paste or open is read by this page and goes nowhere: it is not uploaded, not stored and not sent to analytics. The page counts one anonymous “tool used” event with the tool’s name and nothing else. You can check by opening your browser’s network tab, or by going offline after the page loads.
Get the rules from your server
sudo cat /etc/sudoers /etc/sudoers.d/*

Paste them here. Then confirm what sudo will really do with sudo -l -U <user> for each account, and check syntax with sudo visudo -c before and after any change. Always edit with visudo (or visudo -f /etc/sudoers.d/<file>): a syntax error in sudoers can lock every administrator out of sudo.

What it checks

  • Root for everyone or without a password: ALL ALL=(ALL) ALL, NOPASSWD: ALL, and the same through a group.
  • Programs that hand out a shell: editors, pagers, interpreters and shells (vim, less, man, python, perl, awk, find, env and others), which give full access whatever their arguments.
  • Programs that are only safe with fixed arguments: tar, systemctl, docker, apt, rsync, tee, cp and others, flagged when the rule allows any arguments.
  • Wildcards in arguments, which match more than they appear to.
  • Commands in directories users often control: /home, /tmp, /var/www, /srv and /opt.
  • Defaults that weaken every rule: !authenticate, !env_reset, env_keep with LD_PRELOAD, PYTHONPATH and similar, setenv, unlimited timestamp_timeout, !use_pty.
  • Rules that do not do what they say: ALL minus a command, commands without a full path, undefined aliases.

It reads aliases (User_Alias, Cmnd_Alias), continuation lines, #include and @includedir, and tags such as NOPASSWD and SETENV the way sudo carries them from one command to the next in a list.

Related

Questions

Is my sudoers file uploaded?

No. The checker runs in your browser; nothing you paste leaves the page, and nothing is stored or sent to analytics. The page counts one anonymous "tool used" event with the tool's name only.

Can this tell me exactly what a user is allowed to do?

No, and no static reading can. The real answer depends on every file sudo reads (including everything in /etc/sudoers.d), the user's group memberships, the host name, and who can write to the programs and scripts the rules point at. On the server, sudo -l -U <user> prints what sudo will actually allow that user, and visudo -c checks every file for syntax. This tool explains what the text grants and points out the patterns that grant more than they appear to.

Why is allowing vim, less or python as root the same as allowing everything?

Because each of them can start another program. From vim you can run :!sh, from less you can type !sh, and python -c can do anything. If sudo runs them as root, the shell they start is a root shell. GTFOBins documents the escape for each such program. For editing a root-owned file, grant sudoedit instead: it copies the file, lets the user edit the copy with their own editor as themselves, and writes it back as root.

What is wrong with a * in a sudo rule?

In a command's arguments, a * also matches spaces, slashes and dots, so /bin/cat /var/log/* allows /bin/cat /var/log/../../etc/shadow, and /usr/bin/systemctl restart * allows any unit and extra options. sudoers(5) warns about this. List each permitted command line in full, or point the rule at a small wrapper script that root owns.

Is NOPASSWD always wrong?

No. Automation often needs it. The risk is NOPASSWD on ALL, or on a program that can start a shell, because then anything that can run as that user (a compromised web application, a stolen deploy key) becomes root with no further secret. NOPASSWD on one exact, fixed command line is a reasonable trade.