Bugzilla – Bug 563
mail_no_perms seems to not work?
Last modified: 2012-09-12 15:01:50 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.
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.
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.
(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.
Uhm.. ok.. well... perhaps that order, and the dependecies, should be documented among the mail_* options? Cheers, Chris.
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.
This is fixed in sudo 1.8.6.