I want to check if a user is able to use sudo - but without the need to write the password - for bash shell scripts purposes. I did some research and I found:

For a user that does not have a configuration through in sudoers - therefore impossible to use sudo - the execution of sudo -n <command> always prints in the terminal the sudo: a password is required message. And if the user can use sudo --whether sudo was not executed in the session or the sudo's timeout expired -- it prints again the sudo: a password is required message.

Additionally, with the correct solution (but for the other scenario)

$(sudo -n uptime 2>&1 | grep "load" | wc -l)

For an user without sudo permission always returns 0. And if the user can use sudo and if the sudo's timeout is still valid - it returns 1, otherwise it returns 0

Problem: so with this approach is not possible really know through a command know if the user can use sudo - the solution is only viable to know if the sudo's timeout is still valid or not.

With sudo -v so far almost the solution happens the following:

For an user that does not have a configuration about sudoers the command returns

Sorry, user <username> may not run sudo on <hostname>.

If the user can use sudo then the sudo -v asks for the password. If either it is valid or sudo's timeout is still valid it returns empty. So until here there is a clear difference and the solution but because I am working with Bash Shell and I need use Command Substitution

is_user_sudo=$(sudo -v) # if is empty sudo can be used otherwise not

Problem I want avoid the password prompt part. That would be a solution.

Or if exists other parameter such as sudo -k that does not ask for the password (of course it does other thing) or other command to accomplish my goal.

Goal: only the non-root users - that can use sudo - can be able to execute some bash scripts. Therefore internally in the script I need the command to identify that type of non-root user - so the non-root users that can't not use sudo must be notified and stop the script execution.

For example:

# an if statement about 'id -u' not equals a 0
can_use_sudo=$(<command> whoami) # so the non-root user 
                                 # is able to use sudo or not?

whoami can be replaced by other command, that identifies who is running the script

  • Sudoers config can be very specific, allowing for some commands but not others. Also it may allow running as only specific users. Are you wanting to just answer "Is there at least one command this user can successfully run through sudo, as some user?" or are you wanting to verify unlimited root sudo access, or somewhere in between?
    – Wildcard
    Feb 25, 2022 at 0:03
  • Both scenarios have sense. But mostly the latter. Feb 25, 2022 at 12:20
  • 1
    Can you please edit your question and explain what the final objective is? Only root can know the details of what users are allowed to run what commands, anything else would be a huge security breach. Do you want to have any user be able to check if any other user can run any command as any user with sudo?
    – terdon
    Feb 25, 2022 at 13:12
  • @terdon added the goal section Feb 25, 2022 at 13:23
  • 1
    So what you are actually asking is how can this user know if they can run a specific command? You don't need userA to be able to check if userB has access, each user only needs to check for themselves? And what doe s"use sudo" mean? Do you mean "use sudo to run a command as root" or "use sudo to run a command as some other user, not necessarily root"? And one last thing, your sudo user will have to enter a password to run the command, so why do you object to the password prompt?
    – terdon
    Feb 25, 2022 at 13:31

3 Answers 3


I admit that I don't quite understand why you would want this and why you don't just run sudo whoami or something at the beginning of the script to immediately ask users for a password and exit if they cannot continue, but no matter. This should work, at least on Linux systems (haven't checked other sudo implementations):

sudo_response=$(SUDO_ASKPASS=/bin/false sudo -A whoami 2>&1 | wc -l)
if [ $sudo_response = 2 ]; then
elif [ $sudo_response = 1 ]; then
    echo "Unexpected sudo response: $sudo_response" >&2
    exit 1

The trick here is to take advantage of the askpass option of sudo which tries to use another program to validate the password. By setting it to /bin/false, we can get two standard responses based on whether the user can run sudo commands as root or not:

## A user with sudo rights
terdon@tpad $ SUDO_ASKPASS=/bin/false sudo -A whoami 2>&1 
sudo: no password was provided
sudo: a password is required

## A user without sudo rights
bib@tpad $ SUDO_ASKPASS=/bin/false sudo -A whoami
bib is not in the sudoers file.  This incident will be reported.

Therefore, if the response after redirecting stderr to stdout is two lines, the user can run sudo commands and if it is one, the user cannot.

Important: I haven't tested this extensively, I have only tried two users as shown above on a single Arch Linux system. I wouldn't be surprised if this doesn't work as expected on other systems if the output of the command above can change.

For an obvious fail case: this will not work if the user is configured to run sudo commands without a password.

  • Your first sentence has sense and was evaluated from the beginning - but be asking the password each 5 minutes (default sudo's timeout) or many times throughout the day is annoying for some users. And of course, I created this post assuming that is possible do this without asking the password, something like sudo -k is able to do. Feb 25, 2022 at 15:39
  • 1
    @ManuelJordan if you want to exit if the user cannot run sudo, then you just need one password prompt, no need to check without prompting. You have two cases: 1) the user cannot run sudo commands, so the script exits at the first sudo or 2) the user can run sudo commands which means they will have to be prompted for a password. So I don't understand why you would want something this complicated and unsafe. If you want to avoid prompting multiple times, that is a different question and is possible: usually this is done by running sudo script.sh instead of having sudo in the script.
    – terdon
    Feb 25, 2022 at 15:45
  • If you want to check for passwordless users, after can_sudo=0, add an if to check if $(SUDO_ASKPASS=/bin/false sudo -A whoami 2>&1) equals to root, this will also make it work in the sudo timeout Feb 24, 2023 at 10:23
  • There is a third option. If the user has configured their sudoers file with NOPASSWD, the sudo will succeed and "root" will be printed. Feb 20 at 15:27

I haven't found explicit confirmation, but I think that by design there is no way to do this without authentication or permissions.

I don't think an unprivileged user should be able to choose an arbitrary user and an arbitrary command and check if that user has permissions to run that command with sudo. This would greatly aid any attacker in probing the system to learn which accounts would be most valuable to compromise, and it's unclear what benefit it would bring.

Notably, the /etc/sudoers file is locked down by default and not readable except to root.


I want check through a command if an user is able to use sudo - but without the need to write the password

groups user_name will show all groups a user is a member of. If the user is a member of the sudo group, then the user might be able to use sudo (as @terdon points out group membership is not what grants permission to use sudo, but in the typical case where users are created simply as either "regular users" or "administrators", sudo group membership correlates with being able to use sudo).

if [ -z "$(groups user_name | grep sudo)" ]; then
    echo 'user is not in sudo group'
    echo 'user is in sudo group'

Of course this won't tell you about any finer-grained permissions that might be in the sudoers file - you need root to read that.

  • 8
    This could indeed work in some cases, but note that the sudo group is just a name used by some systems. There is no requirement that sudo users be in a group specifically called sudo, and in fact may systems use wheel instead. In any case, a system could have whatever name the sysadmin has chosen, this is entirely configurable.
    – terdon
    Feb 25, 2022 at 9:12
  • ... and that is completely configurable per machine. It is not necessarily the case that there is any group that confers elevated privileges on members, even for OS distributions that ordinarily provide such a group. Furthermore, where there is such a group, it is in no way guaranteed that non-members are without sudo privileges. Also, exactly what privileges sudo provides is highly configurable, and not necessarily consistent across users and groups. Feb 25, 2022 at 14:20
  • @terdon true. I was considering only the generic case where users are created as either "regular users" or "administrators" using preconfigured settings. Feb 25, 2022 at 17:03
  • @fuzzydrawings even then, I am not at all sure that sudo is more common than wheel as the default sudoers group.
    – terdon
    Feb 25, 2022 at 17:11
  • @terdon I suppose it depends a lot on which Linux distribution is being used. Feb 25, 2022 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .