Hide Forgot
Description of problem: after upgrade form sssd-2.0.0-43.el8 rhel-8.0 to sssd-2.2.0-1.el8 sudo it not able to gather complete sudoers rule for ldap via sssd. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. use linked test case in 1minutetip rhel-8.0.0 2. update to rhel-8.1.0 sssd version 3. Actual results: sudo complains with 'sudo: no tty present and no askpass program specified' wich should not as a default '!requiretty' is in place Expected results: sudo should not require tty, according to configuration
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