Full_Name: Wesley Craig Version: 1.2.11 OS: Solaris 2.6 URL: Submission from: (NULL) (141.211.164.29) In derefDN(), in back-ldbm/alias.c around line 281, there are two calls, dn2entry_r() and derefAlias_r(), both of which are assumed to return a locked entry. However, these entries are actually the same, unless the first actually contained an alias. Moreover, since the entry was only locked in dn2entry_r(), not in derefAlias_r(), the *two* calls to cache_return_entry_r() cause the RDWR lock to possibly go negative. Once the RDWR lock has been corrupted, wackiness ensues. I found this bug by insert consistency checking in the RDWR code, e.g. that the count of readers, writers, and waiters should never be negative. The server immediately showed the error when doing ldapsearch with -a always. Since I'm not sure what derefDN() is supposed to be doing, I'm at a lose to fix it. :wes
At 06:56 PM 6/16/00 GMT, wes@umich.edu wrote: >I found this bug by insert consistency checking in the RDWR code, e.g. >that the count of readers, writers, and waiters should never be negative. >The server immediately showed the error when doing ldapsearch with -a always. >Since I'm not sure what derefDN() is supposed to be doing, I'm at a lose >to fix it. I don't see this behavior in devel codes (though I've fixed a number of other aliasing problems). Likely need to carefully review the differences and backport key changes. Can you verify that I've added appropriate asserts to devel code to detect this? Also, we likely should add an alias test to our suite just to make sure we're both testing the same thing. Kurt
moved from Incoming to Software Bugs
changed state Open to Suspended
> From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> > To: wes@umich.edu > At 06:56 PM 6/16/00 GMT, wes@umich.edu wrote: > >I found this bug by insert consistency checking in the RDWR code, e.g. > >that the count of readers, writers, and waiters should never be negative. > >The server immediately showed the error when doing ldapsearch with -a always. > >Since I'm not sure what derefDN() is supposed to be doing, I'm at a lose > >to fix it. > I don't see this behavior in devel codes (though I've fixed a > number of other aliasing problems). Likely need to carefully > review the differences and backport key changes. Can > you verify that I've added appropriate asserts to devel code > to detect this? Also, we likely should add an alias test to > our suite just to make sure we're both testing the same thing. The assert()s in the dev code look good. The alias code in dev bears very little resemblance to the 1.2 code. I exercised this bug in 1.2 with a sub-tree search for an entry that existed. The bug was triggered during base analysis, not during the search. For my production environment, I've disable alias dereferencing altogether, since I'm not using any aliases. Is alias support in LDAPv2 a UMICH extension? If so, I'd suggest disabling it in the OpenLDAP 1.2 branch and not worrying about it. :wes
At 11:53 AM 6/18/00 -0400, wesley.craig@umich.edu wrote: >Is alias support in LDAPv2 a UMICH extension? No. LDAPv2 has alias support in the protocol. U-Mich never implemented aliases. We did back in 1.1... but it's a bit problematic. Even the 2.0 alias code, though more stable, isn't feature complete (when "searching", it only supports aliases which refer to leafs). >If so, I'd suggest >disabling it in the OpenLDAP 1.2 branch and not worrying about it. I suggest folk avoid aliases in 1.2 until fixed. Placing the following ACL should stop aliases from being added to the directory: access to attr=aliasedObjectName by * read (but letting them read them if they preexist). As far as fixing it... I'll place it appropriately on my very long TODO list :-). I'll see if Will, the original author, is more worrisome. Kurt
patch file: pturgyan-000629.patch This patch for 1.2.11 corrects the dn translation of an alias that points to a non-leaf entry. Without the patch, ldapsearch reports the following error: 77:% ldapsearch -b "cn=Paul R Turgyan 1,ou=ITD,ou=Faculty and Staff,ou=People, o=University of Michigan, c=US" -s base -a always objectclass="*" ldap_search: Alias dereferencing problem ldap_search: additional info: Maximum alias dereference depth exceeded for base and slapd logs the following error: Jun 21 13:47:14 bat.umich.edu slapd[9]: <= max deref depth exceeded in derefDN for "CN=PAUL R TURGYAN 1,OU=ITD,OU=FACULTY AND STAFF,OU=PEOPLE,O=UNIVERSITY OF MICHIG AN,C=US", result "CN=PAUL R TURGYAN 1,ou=ITD,ou=Faculty and Staff, ou=People, o=University of Michigan, c=US" This patch does not correct the locking problem that Wes Craig previously reported. I didn't see this dn translation problem in 2.0 while reading the code.
changed notes
changed state Suspended to Closed
fixed in devel