Bug 536

Summary: No error message when command is missing or lacks permissions
Product: Sudo Reporter: ulrik.haugen
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED FIXED    
Severity: normal    
Priority: low    
Version: 1.7.4   
Hardware: PC   
OS: Linux   

Description ulrik.haugen 2012-02-10 05:15:17 MST
I have a line in sudoers permitting the nagios user to run an nrpe plugin as root without entering a password (the account has no password set). I have also asked Sudo not to insist on a tty in order to not be refused to not enter a password over a line where echo can not be disabled:

Defaults:nagios !requiretty
nagios ALL = (ALL) NOPASSWD: /opt/liu/bin/monitor-sync-state ""


Asking Sudo what commands I may run seems to confirm that I have succeeded in configuring this:


-sh-4.1$ sudo -l
Matching Defaults entries for nagios on this host:
    requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
    DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
    PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
    LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
    LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
    LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, !requiretty

User nagios may run the following commands on this host:
    (ALL) NOPASSWD: /opt/liu/bin/monitor-sync-state
    \"\"


Asking Sudo to run the command for me however insists on a password none the less:

-sh-4.1$ sudo /opt/liu/bin/monitor-sync-state
[sudo] password for nagios: 
Sorry, try again.
[sudo] password for nagios: 
Sorry, try again.
[sudo] password for nagios: 
Sorry, try again.
sudo: 3 incorrect password attempts

If I instead do this over a line that is not a tty I am presented with condolences about not wanting to ask me about the password on that line.

After a few hours of trying to figure out why Sudo is ignoring my NOPASSWD directive it turns out that the reason is missing execute permissions on the nrpe plugin I'm trying to run. This bug will also be triggered if the file doesn't exist.

I had expected an error message describing the actual problem rather than the behavior exhibited.


Best regards
/Ulrik Haugen

# sudo -V       
Sudo version 1.7.4p5

Configure args: --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --sbindir=/usr/sbin --libdir=/usr/lib64 --docdir=/usr/share/doc/sudo-1.7.4p5 --with-logging=syslog --with-logfac=authpriv --with-pam --with-pam-login --with-editor=/bin/vi --with-env-editor --with-ignore-dot --with-tty-tickets --with-ldap --with-ldap-conf-file=/etc/nslcd.conf --with-selinux --with-passprompt=[sudo] password for %p:  --with-linux-audit
Sudoers path: /etc/sudoers
nsswitch path: /etc/nsswitch.conf
ldap.conf path: /etc/nslcd.conf
ldap.secret path: /etc/ldap.secret
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: authpriv
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Ignore '.' in $PATH
Send mail if the user is not in sudoers
Use a separate timestamp for each user/tty combo
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5,0 minutes
Password prompt timeout: 5,0 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to mail program: /usr/sbin/sendmail
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: *** SECURITY information for %h ***
Incorrect password message: Sorry, try again.
Path to authentication timestamp dir: /var/db/sudo
Default password prompt: [sudo] password for %p: 
Default user to run commands as: root
Path to the editor for use by visudo: /bin/vi
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File containing dummy exec functions: /usr/libexec/sudo_noexec.so
File descriptors >= 3 will be closed before executing a command
Reset the environment to a default set of variables
Environment variables to check for sanity:
        TERM
        LINGUAS
        LC_*
        LANGUAGE
        LANG
        COLORTERM
Environment variables to remove:
        RUBYOPT
        RUBYLIB
        PYTHONUSERBASE
        PYTHONINSPECT
        PYTHONPATH
        PYTHONHOME
        TMPPREFIX
        ZDOTDIR
        READNULLCMD
        NULLCMD
        FPATH
        PERL5DB
        PERL5OPT
        PERL5LIB
        PERLLIB
        PERLIO_DEBUG 
        JAVA_TOOL_OPTIONS
        SHELLOPTS
        GLOBIGNORE
        PS4
        BASH_ENV
        ENV
        TERMCAP
        TERMPATH
        TERMINFO_DIRS
        TERMINFO
        _RLD*
        LD_*
        PATH_LOCALE
        NLSPATH
        HOSTALIASES
        RES_OPTIONS
        LOCALDOMAIN
        CDPATH
        IFS
Environment variables to preserve:
        XAUTHORIZATION
        XAUTHORITY
        TZ
        PS2
        PS1
        PATH
        LS_COLORS
        KRB5CCNAME
        HOSTNAME
        DISPLAY
        COLORS
Locale to use while parsing sudoers: C
Local IP address and netmask pairs:
        130.236.141.18 / 255.255.255.252
        fe80::1aa9:5ff:fe4e:906a / ffff:ffff:ffff:ffff::
Comment 1 Todd C. Miller 2012-02-10 15:00:19 MST
I've merged a change from the sudo 1.8 branch that fixes this when the file exists but is not executable.  The fix will be in sudo 1.7.9.

However, because sudo matches commands based on their inode number, if the file doesn't exist it won't match sudoers and thus NOPASSWD will not be applied.  This is not fixable with the current sudoers file, but will be addressed in sudo 2.0 with a new sudoers format.
Comment 2 Todd C. Miller 2012-02-21 06:04:00 MST
The missing error message on bad permissions bug is fixed in sudo 1.7.9.