Bug 563

Summary:	mail_no_perms seems to not work?
Product:	Sudo	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	low
Version:	1.8.3
Hardware:	All
OS:	Linux

Description Christoph Anton Mitterer 2012-07-01 19:40:01 MDT

Hi.

I'm having the following sudo configuration:
Defaults: cgi-suexec    authenticate, !setenv, !preserve_groups, !closefrom_override
Defaults: cgi-suexec    env_reset, !env_file, always_set_home, set_home, set_logname, secure_path="/usr/bin:/bin", umask=0022
Defaults: cgi-suexec    !requiretty, !pwfeedback, !visiblepw, !umask_override, !stay_setuid, closefrom=3, timestamp_timeout=0, !shell_noargs, runas_default=nobody, !r
oot_sudo
Defaults: cgi-suexec    ignore_dot, !fast_glob
Defaults: cgi-suexec    mail_no_perms, mail_no_host
Defaults: cgi-suexec    lecture=never, !path_info
cgi-suexec      ALL     =       (cgi-icinga-cgi)        NOPASSWD: SETENV:       /usr/lib/cgi-bin/icinga/*.cgi ""
cgi-suexec      ALL     =       (cgi-icinga-web)        NOPASSWD: SETENV:       /usr/lib/cgi-bin/php ""


Now I tried things like (to see whether * can be used to match .. ;) ):
cgi-suexec@host$ sudo -n -E -H -k -u root -- /tmp/id.cgi 
sudo: sorry, a password is required to run sudo
cgi-suexec@host:~$ sudo -n -E -H -k -u root -- /usr/lib/cgi-bin/icinga/../../../../tmp/id.cgi
sudo: sorry, a password is required to run sudo
cgi-suexec@host:~$ sudo -n -E -H -k -u cgi-icinga-cgi -- /usr/lib/cgi-bin/icinga/../../../../tmp/id.cgi
sudo: sorry, a password is required to run sudo

and the same ones without -n -E -H -k, in which case it asks for passwords (which I entered incorrectly, until sudo gave up).


Now I'd have expected that I get mail_no_perms warnings in any case, as I just tried to execute invalid path. But no single such warning occured.
Mail sending itself obviously works, because in the cases without -n -E -H -k I got mails about inccorect password tries.


Is there any problem or am I just stupid?! ;)

Thanks,
Chris.

Comment 1 Todd C. Miller 2012-07-03 14:25:05 MDT

The check for whether a command is allowed or not is done after the user authenticates.  Since you are using the -n flag, authentication never succeeds and so the permission check is not done.

In this case, I think it makes more sense for sudo to mail if "mail_badpass" is set.

Comment 2 Christoph Anton Mitterer 2012-07-03 19:04:55 MDT

Well...

a) as I said, I tried with out -n, too, and it didn't work.

b) an now I have a system (SL6 with stone aged 1.7.4p5), where mail_badpass is NOT set per default as in Debian, and with the options above, but where also no mail about wrong commands are sent.


Cheers,
Chris.

Comment 3 Todd C. Miller 2012-07-05 14:08:26 MDT

(In reply to comment #2)

If you don't enter the correct password the user's sudoers commands won't be evaluated yet and so you won't get mail sent for mail_no_perms, though you will get mail if you have mail_badpass set.

Comment 4 Christoph Anton Mitterer 2012-07-09 13:31:51 MDT

Uhm.. ok.. well... perhaps that order, and the dependecies, should be documented among the mail_* options?


Cheers,
Chris.

Comment 5 Todd C. Miller 2012-07-10 13:19:15 MDT

I've reordered the way things are logged for sudo 1.8.6.  In sudo 1.8.6 mail_no_perms will send mail even if the user doesn't authenticate successfully which should address your issue.

Comment 6 Todd C. Miller 2012-09-12 15:01:50 MDT

This is fixed in sudo 1.8.6.