Bug 1729055
Summary: | sssd does not pass correct rules to sudo | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Dalibor Pospíšil <dapospis> | ||||||||
Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | sssd-qe <sssd-qe> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 8.1 | CC: | abokovoy, dlavu, grajaiya, jhrozek, lslebodn, mhonek, mmcgrath, mupadhye, mzidek, pbrezina, pkis, sgoveas, tscherf, wchadwic | ||||||||
Target Milestone: | rc | ||||||||||
Target Release: | 8.1 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | sssd-2.2.0-5.el8 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-11-05 22:34:54 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: | |||||||||||
Attachments: |
|
Description
Dalibor Pospíšil
2019-07-11 09:57:23 UTC
for sudo it is kind of blocker The smart refresh includes (modifyTimestamp>=1) filter that causes troubles: # ldapsearch -w x -x -H ldap://my-domain.com -b dc=my-domain,dc=com -D cn=Manager,dc=my-domain,dc=com '(&(&(objectclass=sudoRole)(modifyTimestamp>=1))(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=ci-vm-10-0-137-170.hosted.upshift.rdu2.redhat.com)(sudoHost=ci-vm-10-0-137-170)(sudoHost=10.0.137.170)(sudoHost=10.0.136.0/22)(sudoHost=2620:52:0:88:f816:3eff:feb4:9a02)(sudoHost=2620:52:0:88::/64)(sudoHost=fe80::f816:3eff:feb4:9a02)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))' # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope subtree # filter: (&(&(objectclass=sudoRole)(modifyTimestamp>=1))(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=ci-vm-10-0-137-170.hosted.upshift.rdu2.redhat.com)(sudoHost=ci-vm-10-0-137-170)(sudoHost=10.0.137.170)(sudoHost=10.0.136.0/22)(sudoHost=2620:52:0:88:f816:3eff:feb4:9a02)(sudoHost=2620:52:0:88::/64)(sudoHost=fe80::f816:3eff:feb4:9a02)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*)))) # requesting: ALL # # search result search: 2 result: 0 Success Without the filter it finds the rules successfully: # ldapsearch -w x -x -H ldap://my-domain.com -b dc=my-domain,dc=com -D cn=Manager,dc=my-domain,dc=com '(&(&(objectclass=sudoRole))(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=ci-vm-10-0-137-170.hosted.upshift.rdu2.redhat.com)(sudoHost=ci-vm-10-0-137-170)(sudoHost=10.0.137.170)(sudoHost=10.0.136.0/22)(sudoHost=2620:52:0:88:f816:3eff:feb4:9a02)(sudoHost=2620:52:0:88::/64)(sudoHost=fe80::f816:3eff:feb4:9a02)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))' '*' modifyTimestamp # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope subtree # filter: (&(&(objectclass=sudoRole))(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=ci-vm-10-0-137-170.hosted.upshift.rdu2.redhat.com)(sudoHost=ci-vm-10-0-137-170)(sudoHost=10.0.137.170)(sudoHost=10.0.136.0/22)(sudoHost=2620:52:0:88:f816:3eff:feb4:9a02)(sudoHost=2620:52:0:88::/64)(sudoHost=fe80::f816:3eff:feb4:9a02)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*)))) # requesting: * modifyTimestamp # # defaults, Sudoers, my-domain.com dn: cn=defaults,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: defaults sudoOption: !authenticate sudoOption: !requiretty modifyTimestamp: 20190711093910Z # rule1, Sudoers, my-domain.com dn: cn=rule1,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: rule1 sudoHost: ALL sudoCommand: ALL sudoUser: userallowed modifyTimestamp: 20190711093910Z So the question is why the comparison 20190711093910Z >= 1 fails. The LDAP server used is openldap. Matus, do you know why the comparison '20190711093910Z >= 1' fails to match? Thank you. Created attachment 1589379 [details] old.tar.bz2 Created attachment 1589380 [details] new.tar.bz2 attached logs from /var/log/sssd of old version and the new version Created attachment 1589385 [details]
ldap.ldif
actual ldap data
# rpm -q openldap openldap-2.4.46-9.el8.x86_64 Upstream PR: https://github.com/SSSD/sssd/pull/850 Patch was pushed to master. * master: 6815844daa7701c76e31addbbdff74656cd30bea Steps to reproduce: 1. install openldap server 2. run sssd 3. there are no sudo rules on the server and there are no cached objects 4. you'll see in the logs that sudo smart refresh uses (&(&(objectclass=sudoRole)(modifyTimestamp>=1))... filter (1 instead of proper datetime value) 5. additionally newly added sudo rules are not found by smart refresh Yes, but I think it would be good to avoid grepping debug messages. And instead check that newly added rule is detected after smart refresh interval (especially if this test gets automated). ie: 1. Setup open ldap server (no rules) 2. Run SSSD 3. Wait few seconds so initial full refresh is finished 4. Check with sudo -l (or ldbsearch) that there are no rules 5. Add a rule 6. Wait for smart refresh to finish 7a. Without the patch: sudo -l will not see this rule 7b. With the patch: the rule is visible in sudo -l Reproduce with # rpm -qa sssd sssd-2.2.0-1.el8.x86_64 Reproduction steps: 1) Setup sssd with openldap server 2) As no sudo rule added, check sudo rule for user [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed is not allowed to run sudo on vm-idm-027. 3) add sudo rule dn: cn=defaults,ou=Sudoers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: defaults sudoOption: !authenticate sudoOption: !requiretty dn: cn=rule1,ou=Sudoers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: rule1 sudoHost: ALL sudoCommand: ALL sudoUser: userallowed # ldapadd -x -D "cn=Manager,dc=example,dc=com" -w Secret123 -h vm-idm-020.lab.eng.pnq.redhat.com -f /root/a.ldif adding new entry "cn=defaults,ou=Sudoers,dc=example,dc=com" adding new entry "cn=rule1,ou=Sudoers,dc=example,dc=com" 4) Wait for smart refresh to complete [root@vm-idm-027 ~]# sleep 10 [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed is not allowed to run sudo on vm-idm-027. 5) Wait for full refresh to complete [root@vm-idm-027 ~]# sleep 120 [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed may run the following commands on vm-idm-027: (root) ALL To verification, upgrade sssd ..... ..... ..... Verifying : sssd-krb5-2.2.0-1.el8.x86_64 20/26 Verifying : sssd-krb5-common-2.2.0-5.el8.x86_64 21/26 Verifying : sssd-krb5-common-2.2.0-1.el8.x86_64 22/26 Verifying : sssd-ldap-2.2.0-5.el8.x86_64 23/26 Verifying : sssd-ldap-2.2.0-1.el8.x86_64 24/26 Verifying : sssd-proxy-2.2.0-5.el8.x86_64 25/26 Verifying : sssd-proxy-2.2.0-1.el8.x86_64 26/26 Installed products updated. Upgraded: libipa_hbac-2.2.0-5.el8.x86_64 libsss_idmap-2.2.0-5.el8.x86_64 python3-sssdconfig-2.2.0-5.el8.noarch sssd-2.2.0-5.el8.x86_64 sssd-ad-2.2.0-5.el8.x86_64 sssd-client-2.2.0-5.el8.x86_64 sssd-common-2.2.0-5.el8.x86_64 sssd-common-pac-2.2.0-5.el8.x86_64 sssd-ipa-2.2.0-5.el8.x86_64 sssd-krb5-2.2.0-5.el8.x86_64 sssd-krb5-common-2.2.0-5.el8.x86_64 sssd-ldap-2.2.0-5.el8.x86_64 sssd-proxy-2.2.0-5.el8.x86_64 Complete! 6) Delete the already added sudo rule, ldapdelete -r -x -D "cn=Manager,dc=example,dc=com" -w Secret123 -H ldap://vm-idm-020.lab.eng.pnq.redhat.com cn=defaults,ou=Sudoers,dc=example,dc=com cn=rule1,ou=Sudoers,dc=example,dc=com 7) Remove cache and log and restart sssd [root@vm-idm-027 ~]# systemctl stop sssd; rm -rf /var/lib/sss/db/*; rm -rf /var/log/sssd/*; systemctl start sssd 8) check for sudo rule, [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed is not allowed to run sudo on vm-idm-027. 9) Add sudo rule again [root@vm-idm-027 ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w Secret123 -h vm-idm-020.lab.eng.pnq.redhat.com -f /root/a.ldif adding new entry "cn=defaults,ou=Sudoers,dc=example,dc=com" adding new entry "cn=rule1,ou=Sudoers,dc=example,dc=com" 10) wait for smart refresh to complete [root@vm-idm-027 ~]# sleep 10 [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed may run the following commands on vm-idm-027: (root) ALL 11) Wait for full refresh to complete, [root@vm-idm-027 ~]# sleep 120 [root@vm-idm-027 ~]# sudo -l -U userallowed User userallowed may run the following commands on vm-idm-027: (root) ALL [root@vm-idm-027 ~]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 domains = LDAP services = nss, pam, sudo debug_level = 0xFFFF [nss] filter_groups = root filter_users = root [pam] [sudo] debug_level = 0xFFFF sudo_timed = true [domain/LDAP] id_provider = ldap auth_provider = ldap sudo_provider = ldap debug_level = 0xFFFF ldap_uri = ldap://server.example.com ldap_tls_cacert = /etc/openldap/certs/cacert.asc ldap_search_base = dc=example,dc=com entry_cache_nowait_percentage = 0 entry_cache_timeout = 0 ldap_sudo_smart_refresh_interval = 5 ldap_sudo_full_refresh_interval = 60 From above getting sudo rule so marking this as verified. 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/RHSA-2019:3651 |