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.
Bug 1618702 - sysdb sudo search does not escape special characters
Summary: sysdb sudo search does not escape special characters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sudo
Version: 7.6
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: Dalibor Pospíšil
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1648377 1649308
TreeView+ depends on / blocked
 
Reported: 2018-08-17 11:41 UTC by shridhar
Modified: 2020-03-31 19:43 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
.`sudo` configured using LDAP now handles `sudoRunAsGroup` correctly Previously, the `sudo` tool configured using LDAP did not correctly handle the case when the `sudoRunAsGroup` attribute was defined and the `sudoRunAsUser` attribute was not. As a consequence, the `root` user was used as the target user. With this update, the handling of `sudoRunAsGroup` has been fixed to match the behavior documented in the `sudoers.ldap(5)` man page, and `sudo` now works properly in the described scenario.
Clone Of:
Environment:
Last Closed: 2020-03-31 19:43:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
logs and cache (50.80 KB, application/x-gzip)
2018-08-21 08:33 UTC, shridhar 		no flags Details
newlogs (35.42 KB, application/x-bzip)
2018-08-23 12:22 UTC, shridhar 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1048 0 None None None 2020-03-31 19:43:59 UTC

Description shridhar 2018-08-17 11:41:45 UTC 
Description of problem:
Our sssd sudo testwuit is showing failure for :"sudo rule configured for users and groups with special characters is returned with sudo -l however when user tries to execute that command sudo command does not allow to run the command."



Version-Release number of selected component (if applicable):
sssd-1.16.2-12

How reproducible:
Always

Steps to Reproduce:
Executing sudo testsuite shows the behavior
1. create a user with special charcters  t\(u\)ser and group as well group\(_u\)ser1


Actual results:
-bash-4.2$ sudo /usr/bin/touch /tmp/new
[sudo] password for t(u)ser: 
Sorry, user t(u)ser is not allowed to execute '/usr/bin/touch /tmp/new' as root on vm-idm-031.lab.eng.pnq.redhat.com.
-bash-4.2$ logout


Expected results:
user shoul be able to run the sudo command successfully

Additional info:

~]# service sssd stop ; rm -rf /var/log/sssd/* ; rm -rf /var/lib/sss/db/* ; service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@vm-idm-031 ~]# ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb 
asq: Unable to register control with rootdse!
# record 1
dn: cn=ranges,cn=sysdb
cn: ranges
distinguishedName: cn=ranges,cn=sysdb

# record 2
dn: cn=LDAP,cn=sysdb
cn: LDAP
distinguishedName: cn=LDAP,cn=sysdb

# record 3
dn: cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
cn: sudorules
sudoLastFullRefreshTime: 1534504996
distinguishedName: cn=sudorules,cn=custom,cn=LDAP,cn=sysdb

# record 4
dn: name=single_cn,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
cn: single_cn
dataExpireTimestamp: 1534510396
entryUSN: 20180817103427Z
name: single_cn
objectClass: sudoRule
originalDN: cn=single_cn,ou=Sudoers,dc=example,dc=com
sudoCommand: ALL
sudoHost: ALL
sudoUser: sudo_test_user@ldap
distinguishedName: name=single_cn,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb

# record 5
dn: cn=sysdb
cn: sysdb
description: base object
version: 0.20
distinguishedName: cn=sysdb

# record 6
dn: cn=users,cn=LDAP,cn=sysdb
cn: Users
distinguishedName: cn=users,cn=LDAP,cn=sysdb

# record 7
dn: cn=groups,cn=LDAP,cn=sysdb
cn: Groups
distinguishedName: cn=groups,cn=LDAP,cn=sysdb

# record 8
dn: name=testrule,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
cn: testrule
dataExpireTimestamp: 1534510396
entryUSN: 20180817103758Z
name: testrule
objectClass: sudoRule
originalDN: cn=testrule,dc=example,dc=com
sudoCommand: /usr/bin/touch
sudoHost: ALL
sudoOption: !authenticate
sudoOption: !requiretty
sudoRunAsGroup: group(_u)ser1
sudoUser: t(u)ser@ldap
distinguishedName: name=testrule,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb

# returned 8 records
# 8 entries
# 0 referrals
[root@vm-idm-031 ~]# sudo -l -U  t\(u\)ser
User t(u)ser may run the following commands on vm-idm-031:
    (t(u)ser : group(_u)ser1) NOPASSWD: /usr/bin/touch
[root@vm-idm-031 ~]# su -  t\(u\)ser
Last login: Fri Aug 17 16:50:02 IST 2018 on pts/0
su: warning: cannot change directory to /home/tuser: No such file or directory
/usr/bin/id: cannot find name for group ID 10013
-bash-4.2$ id
uid=10013(t(u)ser) gid=10013 groups=10013,20000(group(_u)ser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-bash-4.2$ sudo /usr/bin/touch /tmp/new
[sudo] password for t(u)ser: 
Sorry, user t(u)ser is not allowed to execute '/usr/bin/touch /tmp/new' as root on vm-idm-031.lab.eng.pnq.redhat.com.
-bash-4.2$ logout
[root@vm-idm-031 ~]# mkdir data
Comment 5 shridhar 2018-08-21 08:32:27 UTC 
both logs and reproducer are available. I'm uploading logs. I could trigger a reproducer system as per your request or you could run the sudo test-suit as well.
Comment 6 shridhar 2018-08-21 08:33:05 UTC 
Created attachment 1477451 [details]
logs and cache
Comment 7 Pavel Březina 2018-08-21 11:32:45 UTC 
Works for me locally. SSSD sudo responder returns rule as expected, I will need full sudo logs as the attached are not verbose enough. See [1] to obtain full sudo logs.

[1] https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-logs
Comment 8 shridhar 2018-08-23 09:48:05 UTC 
Issue still persists. I've reproducer set with 1 day delay time.  user information is as mentioned in the bugzilla description. Emailed the reproducer details.
Comment 9 shridhar 2018-08-23 12:22:24 UTC 
Created attachment 1478145 [details]
newlogs
Comment 10 Pavel Březina 2018-08-23 13:14:29 UTC 
SSSD correctly returns the rule to sudo.

hu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_build_response] (0x2000): rule [1]/[1]
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): cn:testrule
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): objectClass:sudoRule
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoCommand:/usr/bin/touch
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoHost:ALL
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoOption:!authenticate
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoOption:!requiretty
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoRunAsGroup:group(_u)ser1
(Thu Aug 23 15:06:44 2018) [sssd[sudo]] [sudosrv_response_append_attr] (0x2000): sudoUser:#10013

sudoUser attribute is correctly replace with UID, group name in sudoRunAsGroup is corent. Sudo then probably denies access because it is missing sudoRunAsUser:

Aug 23 15:07:08 sudo[14518] state |= HOSTMATCH
Aug 23 15:07:08 sudo[14518] u_sss_result=(0x564f620df290, 1) => f_sss_result=(0x564f620f0e10, 1)
Aug 23 15:07:08 sudo[14518] <- sudo_sss_result_get @ ./sssd.c:957 := 0x564f620f0e10
Aug 23 15:07:08 sudo[14518] searching SSSD/LDAP for sudoers entries
Aug 23 15:07:08 sudo[14518] -> sudo_sss_check_runas @ ./sssd.c:744
Aug 23 15:07:08 sudo[14518] -> sudo_sss_check_runas_user @ ./sssd.c:571
Aug 23 15:07:08 sudo[14518] sudoRunAsUser: no result, trying sudoRunAs
Aug 23 15:07:08 sudo[14518] sudoRunAsUser: no result.
Aug 23 15:07:08 sudo[14518] <- sudo_sss_check_runas_user @ ./sssd.c:594 := -1
Aug 23 15:07:08 sudo[14518] <- sudo_sss_check_runas @ ./sssd.c:753 := false
Aug 23 15:07:08 sudo[14518] Done with LDAP searches

Interesting is that 'sudo_sss_check_runas_user' function was removed recently from sudo in 1.8.24. But the test machine is running sudo-1.8.23-1.el7.x86_6. I seen some upstream development in sssd related code in sudo on sudo-workers recently so maybe there is some bug.

Please, try to add sudoRunAsUser: root to the rule and see if it will work.
Comment 11 shridhar 2018-08-24 10:05:22 UTC 
Executed with sudoRunAsUser: root,  with that user is able to run the sudo command. Unfortunately with that modification sudoRunAsGroup is failing.

[root@qe-blade-01 ~]# systemctl stop sssd.service ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; systemctl start sssd.service
[root@qe-blade-01 ~]# su - t\(u\)ser
Last login: Fri Aug 24 05:38:00 EDT 2018 on pts/0
su: warning: cannot change directory to /home/tuser: No such file or directory
/usr/bin/id: cannot find name for group ID 10013
-bash-4.2$ sudo -g group\(_u\)ser1 /usr/bin/touch /tmp/new4
Sorry, user t(u)ser is not allowed to execute '/usr/bin/touch /tmp/new4' as t(u)ser:group(_u)ser1 on qe-blade-01.idmqe.lab.eng.bos.redhat.com.
-bash-4.2$ logout


I've shared new reproducer details with you over email.
Comment 12 Pavel Březina 2018-08-24 11:08:10 UTC 
Ok, we obviously made some progress when you added sudoRunAsUser: root.

1) sudo touch RECIPE.TXT
This command succeeds and outputs the following sudo log:

Aug 24 06:47:12 sudo[6090] -> sudo_sss_lookup @ ./sssd.c:1167
Aug 24 06:47:12 sudo[6090] -> sudo_sss_result_get @ ./sssd.c:891
Aug 24 06:47:12 sudo[6090] -> sudo_sss_checkpw @ ./sssd.c:549
Aug 24 06:47:12 sudo[6090] <- sudo_sss_checkpw @ ./sssd.c:561 := 0
Aug 24 06:47:12 sudo[6090]   username=t(u)ser
Aug 24 06:47:12 sudo[6090] domainname=NULL
Aug 24 06:47:12 sudo[6090] state |= USERMATCH
Aug 24 06:47:12 sudo[6090] Received 1 rule(s)
[... everything matches here]
Aug 24 06:47:12 sudo[6090] state |= HOSTMATCH
Aug 24 06:47:12 sudo[6090] u_sss_result=(0x560ad69ce290, 1) => f_sss_result=(0x560ad69e0790, 1)
Aug 24 06:47:12 sudo[6090] <- sudo_sss_result_get @ ./sssd.c:957 := 0x560ad69e0790
Aug 24 06:47:12 sudo[6090] searching SSSD/LDAP for sudoers entries
Aug 24 06:47:12 sudo[6090] -> sudo_sss_check_runas @ ./sssd.c:744
Aug 24 06:47:12 sudo[6090] -> sudo_sss_check_runas_user @ ./sssd.c:571
Aug 24 06:47:12 sudo[6090] val[0]=root
Aug 24 06:47:12 sudo[6090] -> userpw_matches @ ./match.c:1011
Aug 24 06:47:12 sudo[6090] user root matches sudoers user root: true @ userpw_matches() ./match.c:1027
[ ^ run as user match]
Aug 24 06:47:12 sudo[6090] <- userpw_matches @ ./match.c:1028 := true
Aug 24 06:47:12 sudo[6090] root == root (pw_name) => match
Aug 24 06:47:12 sudo[6090] sssd/ldap sudoRunAsUser 'root' ... MATCH!
Aug 24 06:47:12 sudo[6090] <- sudo_sss_check_runas_user @ ./sssd.c:689 := 1
Aug 24 06:47:12 sudo[6090] <- sudo_sss_check_runas @ ./sssd.c:753 := true
Aug 24 06:47:12 sudo[6090] -> sudo_sss_check_command @ ./sssd.c:1016
Aug 24 06:47:12 sudo[6090] val[0]=/usr/bin/touch

RunAsGroup attribute is not evaluated at all in this case.

1) sudo -g group\(_u\)ser1 touch RECIPE.TXT
Sorry, user t(u)ser is not allowed to execute '/usr/bin/touch RECIPE.TXT' as t(u)ser:group(_u)ser1 on qe-blade-01.idmqe.lab.eng.bos.redhat.com.

This command fails and outputs the following sudo log:

Aug 24 06:52:38 sudo[8949] -> sudo_sss_lookup @ ./sssd.c:1167
Aug 24 06:52:38 sudo[8949] -> sudo_sss_result_get @ ./sssd.c:891
Aug 24 06:52:38 sudo[8949] -> sudo_sss_checkpw @ ./sssd.c:549
Aug 24 06:52:38 sudo[8949] <- sudo_sss_checkpw @ ./sssd.c:561 := 0
Aug 24 06:52:38 sudo[8949]   username=t(u)ser
Aug 24 06:52:38 sudo[8949] domainname=NULL
Aug 24 06:52:38 sudo[8949] state |= USERMATCH
Aug 24 06:52:38 sudo[8949] Received 1 rule(s)
[... everything matches here]
Aug 24 06:52:38 sudo[8949] state |= HOSTMATCH
Aug 24 06:52:38 sudo[8949] u_sss_result=(0x5624ece70290, 1) => f_sss_result=(0x5624ece82c70, 1)
Aug 24 06:52:38 sudo[8949] <- sudo_sss_result_get @ ./sssd.c:957 := 0x5624ece82c70
Aug 24 06:52:38 sudo[8949] searching SSSD/LDAP for sudoers entries
Aug 24 06:52:38 sudo[8949] -> sudo_sss_check_runas @ ./sssd.c:744
Aug 24 06:52:38 sudo[8949] -> sudo_sss_check_runas_group @ ./sssd.c:698
Aug 24 06:52:38 sudo[8949] val[0]=group(_u)ser1
Aug 24 06:52:38 sudo[8949] -> group_matches @ ./match.c:1041
Aug 24 06:52:38 sudo[8949] group group(_u)ser1 matches sudoers group group(_u)ser1: true @ group_matches() ./match.c:1057
[ ^ runAsGroup attribute is correctly evaluated ]
Aug 24 06:52:38 sudo[8949] <- group_matches @ ./match.c:1058 := true
Aug 24 06:52:38 sudo[8949] sssd/ldap sudoRunAsGroup 'group(_u)ser1' ... MATCH!
Aug 24 06:52:38 sudo[8949] <- sudo_sss_check_runas_group @ ./sssd.c:732 := 1
Aug 24 06:52:38 sudo[8949] -> sudo_sss_check_runas_user @ ./sssd.c:571
Aug 24 06:52:38 sudo[8949] val[0]=root
Aug 24 06:52:38 sudo[8949] -> userpw_matches @ ./match.c:1011
Aug 24 06:52:38 sudo[8949] user t(u)ser matches sudoers user root: false @ userpw_matches() ./match.c:1027
[ ^ runAsUser fails ]
Aug 24 06:52:38 sudo[8949] <- userpw_matches @ ./match.c:1028 := false
Aug 24 06:52:38 sudo[8949] sssd/ldap sudoRunAsUser 'root' ... not
Aug 24 06:52:38 sudo[8949] <- sudo_sss_check_runas_user @ ./sssd.c:689 := 0
Aug 24 06:52:38 sudo[8949] <- sudo_sss_check_runas @ ./sssd.c:753 := false
Aug 24 06:52:38 sudo[8949] Done with LDAP searches

It is definitely not an SSSD bug as SSSD returns the correct rule to sudo and sudo is able to correctly evaluate both user and group. However sudo results are inconsistent depending on presence of sudoRunAsUser and parameters given to sudo.

The problems here seems to be:
A) sudo should not require sudoRunAsUser attribute as it (used to) defaults to root
B) sudo should not fail evaluating sudoRunAsUser in case 2)

I'm setting need info to sudo maintainer. Dan, can you please look at this? Thank you.
Comment 24 shridhar 2019-02-12 14:08:44 UTC 
version of sudo	1.10.0  was used.
Comment 26 shridhar 2019-02-12 15:13:21 UTC 
issue is noticeable with sudo-1.8.23-3.el7.x86_64 as well in  latest testing as well.
Comment 51 errata-xmlrpc 2020-03-31 19:43:43 UTC 
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://access.redhat.com/errata/RHBA-2020:1048
Note You need to log in before you can comment on or make changes to this bug.