Sudo – Prevent Prompting for Password When Running Non-Permitted Command

sudo

I have granted a group permission to run certain commands with no password via sudo. When one of the users makes a typo or runs the wrong command the system prompts them for their password and then they get an error. This is confusing for the user so I'd like to just display an error instead of prompting them for a password. Is this possible?

Here is an example of my sudoers file:

%mygroup ALL=(ALL) NOPASSWD:/usr/local/bin/myscript.sh *

Example when they run the wrong script:

# sudo /usr/local/bin/otherscript.sh
[sudo] password for user:
Sorry, user user is not allowed to execute '/usr/local/bin/otherscript.sh' as root on <hostname>.

Desired output:

Sorry, user user is not allowed to execute '/usr/local/bin/otherscript.sh' as root on <hostname>. Please check the command and try again.

Note the lack of password prompt.

My google-fu has failed me and only returns results on not asking for a password when the user is permitted to run the command.

Best Answer

From a quick read of sudo(8)

   -n          The -n (non-interactive) option prevents sudo from
               prompting the user for a password.  If a password is
               required for the command to run, sudo will display an error
               message and exit.

And for the doubters:

# grep jdoe /etc/sudoers
jdoe    ALL=(ALL) NOPASSWD: /bin/echo
#

Tested thusly:

% sudo echo allowed
allowed
% sudo -n ed             
sudo: a password is required
% sudo ed               

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password:

So an alias for sudo for these folks would likely do the trick, to prevent the password prompt. Now why this requires custom compiling sudo, I don't know, I just read the manual.

Related Solutions

Why sudo Command Executes Without Prompting for Password

Say sudo -K, then retry your test. If it starts asking again, all that was happening is that you had sudo configured to remember your password for some time.

On top of this, Ubuntu's default sudo configuration makes it remember your credentials across ttys. This affects ssh sessions, as you've discovered, since each new ssh connection looks like a new terminal to the low-level OS code.

This also affects things like the graphical Terminal app. If you authenticate with sudo, then create a new tab with Ctrl-Shift-T, you'll find that you don't need to give a password to sudo again in that tab, despite the fact that it also creates a new tty. You can even close the Terminal app entirely, and as long as you restart it within the normal password timeout, sudo will run without requiring you to re-enter your password. This behavior may be enough to make you decide you want to keep this feature enabled.

Mac OS X works this way these days, too.

Not all *ixes do. Red Hat Enterprise Linux (and derivatives like CentOS) insist on getting the password on each new tty.

You can disable both behaviors by changing the Defaults line in /etc/sudoers to something like this:

Defaults=env_reset,timestamp_timeout=0,tty_tickets

The env_reset bit should be there already, and isn't relevant here
The timestamp_timeout directive tells it to immediately time out each sudo session. It's like saying sudo -K after every normal sudo command.
The tty_tickets directive ensures that it associates credentials with the tty they were used on, not just the user name. This is supposed to be the default already, and is documented as such on Ubuntu, but they must have built their distribution of sudo to disable this option, for the convenience reasons given above.

Bash – How to prevent the caller’s shell from being used in sudo

Then answer is that sudo has a bug. First, the workaround: I put this in my /etc/sudoers.d/zabbix file:

zabbix    ALL=(root) NOPASSWD:       /bin/env SHELL=/bin/sh /usr/local/bin/zabbix_raid_discovery

and now subcommands called from zabbix_raid_discovery work.

A patch to fix this will be in sudo 1.8.15. From the maintainer, Todd Miller:

This is just a case of "it's always been like that".  There's not
really a good reason for it.  The diff below should make the behavior
match the documentation.

 - todd

diff -r adb927ad5e86 plugins/sudoers/env.c
--- a/plugins/sudoers/env.c     Tue Oct 06 09:33:27 2015 -0600
+++ b/plugins/sudoers/env.c     Tue Oct 06 10:04:03 2015 -0600
@@ -939,8 +939,6 @@
            CHECK_SETENV2("USERNAME", runas_pw->pw_name,
                ISSET(didvar, DID_USERNAME), true);
        } else {
-           if (!ISSET(didvar, DID_SHELL))
-               CHECK_SETENV2("SHELL", sudo_user.pw->pw_shell, false, true);
            /* We will set LOGNAME later in the def_set_logname case. */
            if (!def_set_logname) {
                if (!ISSET(didvar, DID_LOGNAME))
@@ -984,6 +982,8 @@
            if (!env_should_delete(*ep)) {
                if (strncmp(*ep, "SUDO_PS1=", 9) == 0)
                    ps1 = *ep + 5;
+               else if (strncmp(*ep, "SHELL=", 6) == 0)
+                   SET(didvar, DID_SHELL);
                else if (strncmp(*ep, "PATH=", 5) == 0)
                    SET(didvar, DID_PATH);
                else if (strncmp(*ep, "TERM=", 5) == 0)
@@ -1039,7 +1039,9 @@
     if (reset_home)
        CHECK_SETENV2("HOME", runas_pw->pw_dir, true, true);

-    /* Provide default values for $TERM and $PATH if they are not set. */
+    /* Provide default values for $SHELL, $TERM and $PATH if not set. */
+    if (!ISSET(didvar, DID_SHELL))
+       CHECK_SETENV2("SHELL", runas_pw->pw_shell, false, false);
     if (!ISSET(didvar, DID_TERM))
        CHECK_PUTENV("TERM=unknown", false, false);
     if (!ISSET(didvar, DID_PATH))

Best Answer

Related Solutions

Why sudo Command Executes Without Prompting for Password

Bash – How to prevent the caller’s shell from being used in sudo

Related Question