Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 1RHEL Program Management
2023-08-30 12:17:58 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 2RHEL Program Management
2023-08-30 12:19:00 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.
To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:
"Bugzilla Bug" = 1234567
In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.
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.