How do I check sudo access for a user in Linux? Can I test sudo access from a bash script without triggering a password prompt? And how do I list all the sudo users on a system? These are the questions this guide answers, with real commands and the actual untouched output captured on an Ubuntu server running sudo 1.9.16p2.
A normal user cannot simply read the sudoers file to find out, because it is only readable by root:
ls -l /etc/sudoers-r--r----- 1 root root 1838 Jun 3 13:50 /etc/sudoersSo grep as a normal user fails with Permission denied, which means we need sudo's own built-in options to check privileges. Below are the reliable ways to check sudo access, whether interactively, for another user, or inside a script.
sudo group on Debian/Ubuntu, gets full sudo privileges by default even if there is no individual entry for them. If you want to treat them as a normal user, remove them from that group first.
Quick reference: check sudo access in Linux
| Goal | Command |
|---|---|
| Check if you have sudo access | sudo -l |
| Quick non-interactive test | sudo -n true (exit 0 = passwordless sudo) |
| Validate you can authenticate | sudo -v |
| Check another user's sudo access | sudo -l -U username |
| Check a specific command is allowed | sudo -l /usr/bin/apt |
| Check group membership | groups username |
| List sudo group members (Debian) | getent group sudo |
| List sudo group members (RHEL) | getent group wheel |
| Check if running as root | id -u (returns 0 for root) |
1. Check if you have sudo access with sudo -l
The simplest way to check your own sudo permissions is sudo -l (or sudo --list), which prints the commands you are allowed and forbidden to run on the current host:
sudo -lMatching Defaults entries for golinuxcloud on server1:
env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin, use_pty
User golinuxcloud may run the following commands on server1:
(ALL) NOPASSWD: ALL
(ALL : ALL) ALLThe (ALL) NOPASSWD: ALL line means this user can run any command as any user without a password, while (ALL : ALL) ALL is the standard rule granted by the sudo/wheel group. If you had no sudo access at all, you would instead see User <name> is not allowed to run sudo on <host>.
You can also check whether a specific command is permitted by passing it to sudo -l. It prints the resolved path if the command is allowed:
sudo -l /usr/bin/apt/usr/bin/aptFor a more verbose, rule-by-rule view, repeat the flag as sudo -ll. The downside of sudo -l is that, depending on your sudoers rules, the very first invocation in a session can prompt for your password.
2. Validate sudo access with sudo -v
sudo -v (or sudo --validate) refreshes your cached credentials and is often used to confirm you have sudo access. Be aware that it authenticates the user, so unless all of your sudoers rules are NOPASSWD, it will ask for a password. Running it non-interactively (for example in this shell with no terminal) shows exactly that:
sudo -vsudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is requiredThis is the key reason sudo -v is a poor choice inside scripts, and why the non-interactive approach in the next section is preferred.
3. Test sudo access in a bash script (non-interactive)
For scripting, the gold standard is sudo -n (the -n/--non-interactive flag), which makes sudo fail immediately instead of prompting. The cleanest test is sudo -n true: it runs the harmless true command and tells you, via the exit code, whether passwordless sudo is available.
sudo -n true; echo "exit=$?"exit=0An exit code of 0 means the user has passwordless sudo. A non-zero exit code means sudo would require a password, or the user has no sudo access at all. For a non-sudo user the message is always the same:
sudo -n truesudo: a password is requiredSo a robust check in a script looks like this:
#!/bin/bash
if sudo -n true 2>/dev/null; then
echo "yes, $USER has passwordless sudo access"
else
echo "no, $USER cannot sudo without a password"
fiyes, golinuxcloud has passwordless sudo accessThree-state check: passwordless, needs password, or no sudo
sudo -n true only tells you about passwordless sudo. If you also want to distinguish a user who can sudo but would need to type a password, inspect the output of sudo -nv as well:
#!/bin/bash
prompt=$(sudo -nv 2>&1)
if [ $? -eq 0 ]; then
echo "has_sudo: passwordless"
elif echo "$prompt" | grep -q '^sudo:'; then
echo "has_sudo: password required"
else
echo "no_sudo"
fiHere sudo -nv returns 0 only when no password is needed; when a password would be required it prints a line beginning with sudo: (which we match), and only a user with no sudo entry at all falls through to no_sudo. This three-way logic is what most install scripts rely on to decide whether to ask for your password.
4. Check if another user has sudo access with sudo -l -U
To check sudo access for a different user, run sudo -l -U username as root or as a user who already has sudo. If the user is a sudoer it lists their commands; otherwise it tells you plainly:
sudo -l -U nosudo01User nosudo01 is not allowed to run sudo on server1.There is an important caveat for scripting that most tutorials miss: the exit code of sudo -l -U is 0 even when the user is not a sudoer. The "not allowed" text only goes to the output, not the exit status:
sudo -l -U nosudo01 >/dev/null 2>&1; echo "exit=$?"exit=0So when checking another user inside a script, you must parse the text rather than trust the exit code:
if sudo -l -U "$user" 2>&1 | grep -q 'not allowed'; then
echo "$user is NOT a sudoer"
else
echo "$user is a sudoer"
fi5. Check sudo access via group membership
A user usually gets sudo rights by belonging to an administrative group, which is named sudo on Debian/Ubuntu and wheel on RHEL/Fedora. The groups and id commands show a user's group membership without needing root:
iduid=1000(golinuxcloud) gid=1000(golinuxcloud) groups=1000(golinuxcloud),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),115(lpadmin),981(docker)The presence of 27(sudo) confirms this user is in the sudo group. You can target one user with groups username. In a script you can test it directly:
if id -nG "$USER" | grep -qw sudo; then
echo "$USER is in the sudo group"
fiGroup membership is a strong hint, but remember it is not the only way sudo can be granted, individual rules in /etc/sudoers or /etc/sudoers.d/ can grant access too, which is why sudo -l remains the authoritative check.
6. List all sudo users on the system
To list every user who has sudo access through the admin group, query the group with getent. On Debian/Ubuntu use the sudo group:
getent group sudosudo:x:27:golinuxcloudOn RHEL, Rocky, CentOS or Fedora the equivalent group is wheel:
getent group wheelThe fourth colon-separated field lists the members, which you can extract with getent group sudo | cut -d: -f4. Group membership alone, however, will miss users who were granted sudo through an individual rule. For a complete audit, feed every account to sudo -l -U and drop the ones that are not allowed (run as root):
getent passwd | cut -d: -f1 | xargs -L1 sudo -l -U 2>/dev/null | grep -v 'not allowed'This iterates over all users (including LDAP users that getent exposes) and prints only those who can actually run sudo.
7. Check if a script is already running as root
Sometimes you do not need sudo at all because the script is already running as root. The reliable test is the effective user ID, where 0 is root:
id -u1000In a script, branch on it so you only call sudo when needed:
if [ "$(id -u)" -eq 0 ]; then
echo "running as root, no sudo needed"
else
echo "normal user, will use sudo"
fiThe shell variable $EUID works the same way ([ "$EUID" -eq 0 ]).
8. Understanding /etc/sudoers and /etc/sudoers.d
On modern systems, sudo rules are rarely kept only in /etc/sudoers. Packages and admins drop per-user or per-service rules into the /etc/sudoers.d/ directory, and sudo merges them all. This is why a single user can show several NOPASSWD lines in sudo -l:
sudo ls -l /etc/sudoers.d/-r--r----- 1 root root 37 Jun 3 13:51 99-golinuxcloud-nopasswd
-r--r----- 1 root root 29 Jun 3 13:51 99-root-nopasswd
-r--r----- 1 root root 37 Jun 7 13:23 golinuxcloud
-r--r----- 1 root root 1068 Feb 19 2025 READMEIf you ever see the message "checking for sudo access which may request your password" during an installer (Homebrew, Oh My Zsh and similar tools print it), it simply means the script is about to run a sudo -v style check to confirm you can use sudo before continuing. Always edit sudoers safely with visudo, which validates syntax, and verify the whole configuration with sudo visudo -c.
When you are done testing, you can clear your cached sudo credentials with sudo -k (or sudo --remove-timestamp) so the next sudo command re-evaluates your access from scratch.
Summary
There are several ways to check sudo access in Linux, and the right one depends on the question you are asking. To check your own privileges interactively, use sudo -l to list allowed commands and sudo -v to validate authentication. To check sudo access inside a bash script without a password prompt, use sudo -n true and read the exit code, or the three-state sudo -nv pattern when you also need to detect password-protected sudo.
To check whether another user is a sudoer, run sudo -l -U username, but remember to grep its output for not allowed because the exit code is always 0. Finally, to list sudo users, query the sudo (Debian/Ubuntu) or wheel (RHEL/Fedora) group with getent, and run the full getent passwd | xargs sudo -l -U audit to catch per-user rules in /etc/sudoers.d/. With these commands you can confidently check sudo permissions, test sudo rights in scripts, and audit who has privileges on any Linux system.

