Bug 711906

Summary: ns-slapd segfaults using suffix referrals
Product: [Retired] 389 Reporter: Diego Woitasen <diego>
Component: Directory ServerAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 1.2.8CC: amsharma, jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 712167 (view as bug list) Environment:
Last Closed: 2015-12-07 16:32:45 UTC Type: ---
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: 434915, 708096, 712167    
Attachments:
Description Flags
0001-Bug-711906-ns-slapd-segfaults-using-suffix-referrals.patch nkinder: review+

Description Diego Woitasen 2011-06-08 23:10:02 UTC
Description of problem:
If you configure a suffix referral, ns-slapd sefaults looking up the suffix.


Version-Release number of selected component (if applicable):
1.2.8.3


Steps to reproduce:

1- Create a new DS instance.
2- Create a referral:

ldapadd -x -D "cn=directory manager" -w xxxxx << EOF
dn: ou=referral,dc=localdomain
ou: referral
description: Ingenieria
objectClass: top
objectClass: organizationalUnit

dn: cn=ou\3Dreferral\2Cdc\3Dlocaldomain,cn=mapping tree,cn=config
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: referral
nsslapd-referral: ldaps://otherserver.com:389/ou=foo,o=bar
EOF

3- Do a search:

ldapsearch -x -D "cn=directory manager" -w xxxxx -b dc=localdomain

4- The server will crash just before returning the referal suffix.

 
Actual results:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa401fb70 (LWP 29922)]
0xb7f72144 in slapi_be_select (sdn=0x83563d0) at ldap/servers/slapd/mapping_tree.c:2909
2909    ldap/servers/slapd/mapping_tree.c: No such file or directory.
        in ldap/servers/slapd/mapping_tree.c
#0  0xb7f72144 in slapi_be_select (sdn=0x83563d0)
    at ldap/servers/slapd/mapping_tree.c:2909
#1  0xb7fb8151 in vattr_test_filter (pb=0x8352ba0, e=0x83563d0, f=0x82f46d0,
    filter_type=FILTER_TYPE_PRES, type=0x81822b0 "objectClass")
    at ldap/servers/slapd/vattr.c:432
#2  0xb7f5ac25 in slapi_vattr_filter_test_ext_internal (pb=<value optimized out>,
    e=<value optimized out>, f=0x82f46d0, verify_access=1, only_check_access=0,
    access_check_done=0xa401674c) at ldap/servers/slapd/filterentry.c:894
#3  0xb7f5b106 in slapi_vattr_filter_test_ext (pb=0x2, e=0x83563d0, f=0x82f46d0,
    verify_access=1, only_check_access=0) at ldap/servers/slapd/filterentry.c:839
#4  0xb7f5b1ba in slapi_vattr_filter_test (pb=0x8352ba0, e=0x83563d0, f=0x82f46d0,
    verify_access=1) at ldap/servers/slapd/filterentry.c:787
#5  0xb6414471 in ldbm_back_next_search_entry_ext (pb=0x8352ba0, use_extension=0)
    at ldap/servers/slapd/back-ldbm/ldbm_search.c:1408
#6  0xb6414ab5 in ldbm_back_next_search_entry (pb=0x8352ba0)
    at ldap/servers/slapd/back-ldbm/ldbm_search.c:1141
#7  0xb7f7dd6a in iterate (pb=0x8352ba0, be=<value optimized out>, pnentries=0xa401eda8,
    pagesize=-1, pr_statp=0xa401ed94, send_result=<value optimized out>)
    at ldap/servers/slapd/opshared.c:1141
#8  0xb7f7e2dd in send_results_ext (pb=0x8352ba0, nentries=0xa401eda8, pagesize=-1,
    pr_stat=0xa401ed94, send_result=<value optimized out>)
    at ldap/servers/slapd/opshared.c:1526
#9  0xb7f7ef65 in op_shared_search (pb=0x8352ba0, send_result=1)
    at ldap/servers/slapd/opshared.c:733

Comment 1 Rich Megginson 2011-06-09 02:13:38 UTC
Thanks.  Looks like the fix is a one liner:
--- a/ldap/servers/slapd/mapping_tree.c
+++ b/ldap/servers/slapd/mapping_tree.c
@@ -2905,7 +2905,7 @@ slapi_be_select( const Slapi_DN *sdn ) /* JCM - The name of this should change??
 {
     Slapi_Backend *be;
     mapping_tree_node *node= slapi_get_mapping_tree_node_by_dn(sdn);
-    if(node!=NULL)
+    if((node!=NULL) && (node->mtn_be!=NULL))
         be= node->mtn_be[0];
     else
         be = NULL;

Unfortunately, after the fix, the referral is not returned:
ldapsearch -x -D "cn=directory manager" -w xxxxx -b dc=localdomain
...
# referral, localdomain
dn: ou=referral,dc=localdomain
ou: referral
description: Ingenieria
objectClass: top
objectClass: organizationalUnit

# search result
search: 2
result: 0 Success

# numResponses: 11
# numEntries: 10

I guess because there is an actual entry, it uses it rather than see if there is a suffix referral.  If you need ou=referral,dc=localdomain to be a referral, either remove the real entry, or use a smart referral instead (objectclass: ref) - will investigate some more.

Comment 2 Rich Megginson 2011-06-09 15:42:27 UTC
Created attachment 503925 [details]
0001-Bug-711906-ns-slapd-segfaults-using-suffix-referrals.patch

Comment 3 Rich Megginson 2011-06-09 16:53:14 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   f290f80..fb9b444  master -> master
commit fb9b444fc620a9ccae03d578c7c4b8ed56b82465
Author: Rich Megginson <rmeggins>
Date:   Thu Jun 9 09:39:08 2011 -0600
    Reviewed by: nkinder (Thanks!)
    Branch: master
    Fix Description: Check node->mtn_be for NULL before dereferencing it
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no

Comment 4 Diego Woitasen 2011-06-11 21:58:26 UTC
Comment on attachment 503925 [details]
0001-Bug-711906-ns-slapd-segfaults-using-suffix-referrals.patch

Works for me!

Comment 7 Amita Sharma 2011-07-07 09:33:20 UTC
ldapadd -x -h localhost -p 1389 -D "cn=directory manager" -w Secret123 << EOF
dn: ou=referral1,dc=example,dc=com
ou: referral
description: Ingenieria
objectClass: top
objectClass: organizationalUnit

dn: cn=ou\3Dreferral1\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: referral
nsslapd-referral: ldap://10.65.201.213:1389/ou=People,dc=example,dc=com
EOF

ldapsearch -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=referral1,dc=example,dc=com"


Server did not crash, hence marking bug as VERIFIED.