Red Hat Bugzilla – Bug 1142122
sudo option mail_no_user doesn't work
Last modified: 2016-05-09 08:39:29 EDT
The same problem in rhel 6, tested with sudo-1.8.6p3-12.el6 +++ This bug was initially created as a clone of Bug #1140980 +++ Description of problem: sudo option mail_no_user doesn't work I have following sudoers entries in ldap: dn: cn=defaults,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole sudoOption: !requiretty sudoOption: !authenticate sudoOption: mailto=emailto@domain.com sudoOption: mail_no_user cn: defaults dn: cn=rule1,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: rule1 sudoUser: userallowed sudoHost: ALL sudoCommand: ALL # try sudo with user which isn't in sudoers [test]su - usernotallowed -c 'sudo true' su: warning: cannot change directory to /home/usernotallowed: No such file or directory usernotallowed is not allowed to run sudo on rhel7. This incident will be reported. /var/log/maillog doesn't contain any mail after it. Version-Release number of selected component (if applicable): sudo-1.8.6p7-11.el7 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Works for me. $ postqueue -p shows a queued mail for the configured address.
Are you sure that it works? It doesn't work for me. [test]postqueue -p | wc -l 90 [test]su - usernotallowed -c 'sudo true' su: warning: cannot change directory to /home/usernotallowed: No such file or directory usernotallowed is not allowed to run sudo on rhel6-6. This incident will be reported. [test]postqueue -p | wc -l 90
Is it ldap specific? Have you tried to set the option locally?
Debug logs would be also nice to have...
It looks ldap specific. I don't see this problem with local sudoers. [root@rhel6-6 ldap-sudoers-sanity]# postqueue -p | wc -l 98 [root@rhel6-6 ldap-sudoers-sanity]# su - localuser -c 'sudo true' localuser is not in the sudoers file. This incident will be reported. [root@rhel6-6 ldap-sudoers-sanity]# postqueue -p | wc -l 101 [root@rhel6-6 ldap-sudoers-sanity]# cat /etc/sudoers | grep '^Defaults' Defaults mail_no_user Defaults mailto=emailto@domain.com Defaults !authenticate
[test]postqueue -p | wc -l 118 [test]su - usernotallowed -c 'sudo true' su: warning: cannot change directory to /home/usernotallowed: No such file or directory LDAP Config Summary =================== uri ldap://my-domain.com/ ldap_version 3 sudoers_base ou=Sudoers,dc=my-domain,dc=com binddn (anonymous) bindpw (anonymous) ssl (no) =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_initialize(ld, ldap://my-domain.com/) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_sasl_bind_s() ok sudo: Looking for cn=defaults: cn=defaults sudo: found:cn=defaults,ou=Sudoers,dc=my-domain,dc=com sudo: ldap sudoOption: '!requiretty' sudo: ldap sudoOption: '!authenticate' sudo: ldap sudoOption: 'mailto=emailto@domain.com' sudo: ldap sudoOption: 'mail_no_user' sudo: ldap search '(&(|(sudoUser=usernotallowed)(sudoUser=%groupnotallowed)(sudoUser=%#20002)(sudoUser=ALL))(&(|(!(sudoNotAfter=*))(sudoNotAfter>=20150226141218.0Z))(|(!(sudoNotBefore=*))(sudoNotBefore<=20150226141218.0Z))))' sudo: searching from base 'ou=Sudoers,dc=my-domain,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: ldap search '(&(sudoUser=+*)(&(|(!(sudoNotAfter=*))(sudoNotAfter>=20150226141218.0Z))(|(!(sudoNotBefore=*))(sudoNotBefore<=20150226141218.0Z))))' sudo: searching from base 'ou=Sudoers,dc=my-domain,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: sorting remaining 0 entries sudo: searching LDAP for sudoers entries sudo: done with LDAP searches sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x40 usernotallowed is not allowed to run sudo on rhel6-6. This incident will be reported. [test]postqueue -p | wc -l 118
Well, there seems to be a bug, just not related to the mail options. The options are set as they should be. ... sudo: adding search result sudo: result now has 0 entries ... sudo: user_matches=1 sudo: host_matches=0 ... the mail_no_user has no effect here, because sudo thinks that there was a user match... I'll review the entry matching code.
Created attachment 997109 [details] experimental patch
Created attachment 1022516 [details] proposed patch Fixed patch for the LDAP bug. If there's a bug in SSSD too, create a new BZ for it and with debug logs, please.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1409.html