Bug 2122999 - Defaults option 'mail_no_user' in sudoOption entry does not work via LDAP or SSSD
Summary: Defaults option 'mail_no_user' in sudoOption entry does not work via LDAP or ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sudo
Version: 8.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 2122994
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-31 14:03 UTC by nbubakov
Modified: 2023-08-16 14:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2122994
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-132840 0 None None None 2022-08-31 14:14:17 UTC
Red Hat Issue Tracker SECENGSP-4743 0 None None None 2022-08-31 14:14:27 UTC

Description nbubakov 2022-08-31 14:03:17 UTC
Description of problem:
Defaults entry 'mail_no_user' in sudoOption does not work via LDAP or SSSD provider.

Version-Release number of selected component (if applicable):
tested and failed on all RHEL8 and RHEL9

How reproducible:
Everytime

Steps to Reproduce:
1.a) setup sudo to use ldap, using this ldap data:
  b) setup sudo to use sssd, using this ldap data:

    # my-domain.com
    dn: dc=my-domain,dc=com
    objectClass: dcObject
    objectClass: organization
    dc: my-domain
    o: Test server

    # Groups, my-domain.com
    dn: ou=Groups,dc=my-domain,dc=com
    objectClass: top
    objectClass: organizationalunit
    ou: Groups

    # People, my-domain.com
    dn: ou=People,dc=my-domain,dc=com
    objectClass: top
    objectClass: organizationalunit
    ou: People

    # admin, People, my-domain.com
    dn: cn=admin,ou=People,dc=my-domain,dc=com
    objectClass: top
    objectClass: account
    objectClass: posixAccount
    cn: admin
    uidNumber: 11001
    gidNumber: 21001
    homeDirectory: /home/admin
    loginShell: /bin/bash
    uid: admin
    userPassword:: eA==

    # admin, Groups, my-domain.com
    dn: cn=admin,ou=Groups,dc=my-domain,dc=com
    gidNumber: 21001
    objectClass: top
    objectClass: posixGroup
    cn: 21001
    cn: admin

    # userallowed, People, my-domain.com
    dn: cn=userallowed,ou=People,dc=my-domain,dc=com
    objectClass: top
    objectClass: account
    objectClass: posixAccount
    cn: userallowed
    uidNumber: 10001
    gidNumber: 20001
    homeDirectory: /home/userallowed
    loginShell: /bin/bash
    uid: userallowed
    userPassword:: eA==

    # groupallowed, Groups, my-domain.com
    dn: cn=groupallowed,ou=Groups,dc=my-domain,dc=com
    gidNumber: 20001
    objectClass: top
    objectClass: posixGroup
    cn: groupallowed

    # usernotallowed, People, my-domain.com
    dn: cn=usernotallowed,ou=People,dc=my-domain,dc=com
    objectClass: top
    objectClass: account
    objectClass: posixAccount
    cn: usernotallowed
    uidNumber: 10002
    gidNumber: 20002
    homeDirectory: /home/usernotallowed
    loginShell: /bin/bash
    uid: usernotallowed
    userPassword:: eA==

    # groupnotallowed, Groups, my-domain.com
    dn: cn=groupnotallowed,ou=Groups,dc=my-domain,dc=com
    gidNumber: 20002
    objectClass: top
    objectClass: posixGroup
    cn: groupnotallowed

    # Sudoers, my-domain.com
    dn: ou=Sudoers,dc=my-domain,dc=com
    objectClass: top
    objectClass: organizationalUnit
    ou: Sudoers

    # defaults, Sudoers, my-domain.com
    dn: cn=defaults,ou=Sudoers,dc=my-domain,dc=com
    objectClass: top
    objectClass: sudoRole
    cn: defaults
    sudoOption: !requiretty
    sudoOption: !authenticate
    sudoOption: mailto=emailto
    sudoOption: mail_no_user

    # rule1, Sudoers, my-domain.com
    dn: cn=rule1,ou=Sudoers,dc=my-domain,dc=com
    objectClass: top
    objectClass: sudoRole
    cn: rule1
    sudoUser: userallowed
    sudoHost: ALL
    sudoCommand: ALL

2. use sudo with an unauthorized user to send the email to the recipient:
    $ su - usernotallowed -c 'sudo true'

3. check if the recipient emailto received the email

Actual results:
Email was not sent to emailto:
    Mail queue is empty

Expected results:
Email was sent to emailto:
    ...
    Aug 31 04:44:31 nbubakov-1mt-rhel-8-7-0-20220829-1-49326-2022-08-31-08-24 postfix/smtp[32416]: 872D62400230: to=<emailto>,
    relay=none, delay=0.32, delays=0.29/0/0.02/0, dsn=4.4.1, status=deferred (connect to mx.domain.com[66.96.140.72]:25: Connection refused)
    -Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
    872D62400230     699 Wed Aug 31 04:44:31  usernotallowed.upshift.rdu2.redhat.com
                   (connect to mx.domain.com[66.96.140.72]:25: Connection refused)
                                             emailto

Additional info:
There is no problem with sending an email when writing the sudo default options directly into sudoers file; and/or when there is used any other option (e.g. 'mail_always') with LDAP or SSSD.


Note You need to log in before you can comment on or make changes to this bug.