This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2122994 - 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: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: sudo
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 2122999
TreeView+ depends on / blocked
 
Reported: 2022-08-31 14:00 UTC by nbubakov
Modified: 2023-08-16 08:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2122999 (view as bug list)
Environment:
Last Closed: 2023-08-16 08:55:39 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-1345 0 None None None 2023-08-16 08:55:38 UTC
Red Hat Issue Tracker RHELPLAN-132841 0 None None None 2022-08-31 14:15:08 UTC
Red Hat Issue Tracker SECENGSP-4744 0 None None None 2022-08-31 14:15:18 UTC

Description nbubakov 2022-08-31 14:00:50 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.

Comment 1 Radovan Sroka 2023-08-16 08:55:39 UTC
This bug is going to be migrated.

Contact point for migration questions or issues: rsroka
Guidance for Bugzilla users to test their Jira account or create one if needed:

https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774


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