Bug 1958909
| Summary: | With base object scope, ldapsearch against compat tree does not return any data on Rhel8 IPA servers. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Arya Rajendran <arajendr> |
| Component: | slapi-nis | Assignee: | Alexander Bokovoy <abokovoy> |
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 8.0 | CC: | amore, frenaud, ldap-maint, msauton, pcech, ssidhaye, tapazogl, tbordaz, tmicheli, tmihinto, tscherf |
| Target Milestone: | beta | Keywords: | Regression, TestCaseProvided, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | idm-client-8050020210701113027.de73ecb2 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 18:29:22 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: | |||
side effect of 389-ds-base-bz 1931182 - CVE-2020-35518 389-ds:1.4/389-ds-base: information disclosure during the binding of a DN [rhel-7] https://bugzilla.redhat.com/1931182 [RHEL-7.9.z] https://bugzilla.redhat.com/1904991 [RHEL-8.4] ? This regression appears after https://pagure.io/slapi-nis/c/61ea8f6a104da25329e301a8f56944f860de8177?branch=master That ignores searches not mapping any a mapped one. Moving this bug to slapi-nis (gdb) where #0 backend_search_cb (pb=<optimized out>) at /usr/src/debug/slapi-nis-0.56.6-2.fc34.x86_64/src/back-sch.c:1793 #1 0x00007f9277f228b9 in plugin_call_func (list=0x7f927325de00, operation=operation@entry=403, pb=pb@entry=0x7f9271cea340, call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:2002 ... (gdb) list 1788 slapi_ch_free_string(&target); 1789 return 0; 1790 } 1791 } 1792 slapi_ch_free_string(&target); 1793 if (cbdata.answer == FALSE) { 1794 /* None of the configured trees in the sets matched the target at all, ignore search */ 1795 return 0; 1796 } 1797 } (gdb) print cbdata.answer $16 = 0 We have investigated this issue with Thierry and came up with a fix that works. The original issue was introduced in 2015 and was masked until a recent change that Thierry has pointed to. Upstream fix: https://pagure.io/slapi-nis/c/d18b1d105c928363eddec87af37fda0757cfb440?branch=master Verified using : slapi-nis-0.56.6-3.module+el8.5.0+11645+9d3a3007.x86_64 [root@master ~]# rpm -qa slapi-nis ipa-server slapi-nis-0.56.5-4.module+el8.3.0+8222+c1bff54a.x86_64 ipa-server-4.8.7-16.module+el8.3.0+10289+b6566038.x86_64 [root@master ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=ipa,dc=test" -s base -xLLL Enter LDAP Password: No such object (32) Matched DN: dc=ipa,dc=test ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [root@master ~]# rpm -qa slapi-nis ipa-client slapi-nis-0.56.6-3.module+el8.5.0+11645+9d3a3007.x86_64 ipa-client-4.9.6-3.module+el8.5.0+11816+842aa7e4.x86_64 [root@master ~]# [root@master ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=ipa,dc=test" -s base -xLLL Enter LDAP Password: dn: cn=admins,cn=groups,cn=compat,dc=ipa,dc=test objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: ipaexternalgroup objectClass: top gidNumber: 1923600000 memberUid: admin ipaAnchorUUID:: OklQQTppcGEudGVzdDoyNTQ4NDZjNC1lYTJkLTExZWItYjAwMy1mYTE2M2U4OW QyZDI= cn: admins Test added upstream master: https://pagure.io/freeipa/c/7cac63faefc4a908b6bcf11dfe430ec4e7e8af8a https://pagure.io/freeipa/c/cd665e2d5cfedc5f1f7c7d4ea180cf51af9b51af Test added upstream ipa-4-9: https://pagure.io/freeipa/c/a3d71eb72a6125a80a9d7b698f34dcb95dc25184 https://pagure.io/freeipa/c/d4062e407d242a72b9d4e32f4fdd6aed086ce005 Verified using nightly compose with test_commands.py::TestIPACommandWithoutReplica::test_basesearch_compat_tree 1: runner.log 2021-08-11T10:07:22 ok: [master.ipa.test] => (item=ipa-server) => 2021-08-11T10:07:22 msg: 2021-08-11T10:07:22 - arch: x86_64 2021-08-11T10:07:22 epoch: null 2021-08-11T10:07:22 name: ipa-server 2021-08-11T10:07:22 release: 4.module+el8.5.0+11912+1b4496cf 2021-08-11T10:07:22 source: rpm 2021-08-11T10:07:22 version: 4.9.6 2: test_result.txt 2021-08-11T10:09:47 ============================= test session starts ============================== 2021-08-11T10:09:47 plugins: html-1.22.1, metadata-1.11.0, multihost-3.0, sourceorder-0.5 2021-08-11T10:09:47 collecting ... collected 2 items 2021-08-11T10:17:18 ipatests/test_integration/test_commands.py::TestIPACommandWithoutReplica::test_client_doesnot_throw_responsenotready_error PASSED [ 50%] 2021-08-11T10:17:56 ipatests/test_integration/test_commands.py::TestIPACommandWithoutReplica::test_basesearch_compat_tree PASSED [100%] 2021-08-11T10:17:56 ------------------ generated xml file: /tmp/wp/twd/junit.xml ------------------- 2021-08-11T10:17:56 ------------- generated html file: file:///tmp/wp/twd/report.html -------------- 2021-08-11T10:17:56 ========================== 2 passed in 488.79 seconds ========================== Test test_basesearch_compat_tree is passing based on this marking bug as verified. There is a new Product Owner, so I move needinfo to him. @tmicheli, the fix is already added to 8.5 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 (ipa bug fix and enhancement update), 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-2021:4230 |
Description of problem: On Rhel8 IPA server, there is a difference in ldapsearch behavior against “compat” tree with scope set as “base” compared to Rhel7 IPA server. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux release 8.3 ipa-server-4.8.7-13.module+el8.3.0+8376+0bba7131.x86_64 How reproducible: Always Steps to Reproduce: 1. IPA server with AD trust 2. Run ldapsearch against compact tree with " -s base" # ldapsearch -h 127.0.0.1 -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL Actual results: Rhel7: [root@ipareplica ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL dn: cn=admins,cn=groups,cn=compat,dc=example,dc=com objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: ipaexternalgroup objectClass: top gidNumber: 1769000000 memberUid: admin ipaAnchorUUID:: OklQQTpzdWIuaXBhZXhhbXBsZS5jb206ODE5MmRlZDAtYTBjZC0xMWVhLWI1MD ItMDAxYTRhMjIzYWEy cn: admins [root@ipareplica ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s sub -xLLL dn: cn=admins,cn=groups,cn=compat,,dc=example,dc=com objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: ipaexternalgroup objectClass: top gidNumber: 1769000000 memberUid: admin ipaAnchorUUID:: OklQQTpzdWIuaXBhZXhhbXBsZS5jb206ODE5MmRlZDAtYTBjZC0xMWVhLWI1MD ItMDAxYTRhMjIzYWEy cn: admins Rhel8: [root@ipa1 ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL Enter LDAP Password: No such object (32) Matched DN: dc=example,dc=com [root@ipa1 ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s sub -xLLL Enter LDAP Password: dn: cn=admins,cn=groups,cn=compat,dc=example,dc=com objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: ipaexternalgroup objectClass: top gidNumber: 964400000 memberUid: admin ipaAnchorUUID:: OklQQTphZGkuY29tOjA2ZWZhMGMwLTViZDMtMTFlYi04MDNmLTAwMWE0YTIyMz k5Mw== cn: admins Expected results: ldapsearch with scope set as base should return correct information. Additional info: There are no code changes between RHEL 7 and RHEL 8 versions of slapi-nis with regards to this behavior. This is controlled by the function 'backend_should_descend()' which has the following definition which didn't change since 2008: static bool_t backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) { switch (scope) { case LDAP_SCOPE_BASE: /* The target DN needs to be a subordinate of this entry, but * not actually be the entry itself. */ if ((slapi_sdn_issuffix(target_dn, this_dn) != 0) && (slapi_sdn_compare(target_dn, this_dn) != 0)) { return TRUE; } break; case LDAP_SCOPE_ONELEVEL: /* The target DN needs to be a subordinate of this entry, or * be the entry itself. */ if (slapi_sdn_issuffix(target_dn, this_dn) != 0) { return TRUE; } break; case LDAP_SCOPE_SUBTREE: /* The target DN needs to be a subordinate of this entry, or * this entry needs to be a subordinate of the target. */ if ((slapi_sdn_issuffix(target_dn, this_dn) != 0) || (slapi_sdn_issuffix(this_dn, target_dn) != 0)) { return TRUE; } break; default: break; } return FALSE; }