Bug 1618702
| Summary: | sysdb sudo search does not escape special characters | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | shridhar <sgadekar> | ||||||
| Component: | sudo | Assignee: | Radovan Sroka <rsroka> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> | ||||||
| Severity: | unspecified | Docs Contact: | Mirek Jahoda <mjahoda> | ||||||
| Priority: | high | ||||||||
| Version: | 7.6 | CC: | abokovoy, cpelland, dapospis, grajaiya, jhrozek, lslebodn, mjahoda, mkosek, mzidek, pasik, pbrezina, rsroka, sgadekar, tscherf | ||||||
| Target Milestone: | rc | Keywords: | Documentation, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| 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.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-03-31 19:43:43 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1648377, 1649308 | ||||||||
| Attachments: |
|
||||||||
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. Created attachment 1477451 [details]
logs and cache
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 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. Created attachment 1478145 [details]
newlogs
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. 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. 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. version of sudo 1.10.0 was used. issue is noticeable with sudo-1.8.23-3.el7.x86_64 as well in latest testing as well. 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 |
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