openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by rmeggins＠redhat.com 18 Jan '11

18 Jan '11

The problem is that NSS does not provide an error code to descriptive error string mapping. It needs to be added. Can the Subject of this bug be changed to something like LDAP_OPT_DIAGNOSTIC_MESSAGE should return descriptive message when using MozNSS for TLS

1 0

(ITS#6796) overlay proxycache
by varnakov-k＠ya.ru 18 Jan '11

18 Jan '11

Full_Name: Varnakov Kiril Version: openldap-sasl-server-2.4.23 OS: FreeBSD 8.0-RELEASE-p3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.235.170.154) Hi. When i configure ldap server with overlay proxycache and set pcachePersist=TRUE, only positive answer stay in cache after restart proxy ldap. If not restart proxy ldap, all good, negative answer in cache stay. Why? proxyTemplate (target=) 0 18400 18400

1 0

(ITS#6795) syncprov leaks sr_ctrls
by hyc＠OpenLDAP.org 17 Jan '11

17 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In syncprov_search_response() the control created by syncprov_state_ctrl() can be leaked because the REP_CTRLS_MUSTBEFREED flag was not set.

1 0

(ITS#6794) slapadd -q problems on glued databases
by rhafer＠suse.de 17 Jan '11

17 Jan '11

Full_Name: Ralf Haferkamp Version: 2.4.23, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.17.9) If in a glued (hdb/bdb) setup the subordinate database has more indexes defined than the superior database "slapadd -q" (with a LDIF that spans both databases) will crash with a segfault, when adding the first entry to the subordinate database. Sample config: ------------------ [..] database hdb suffix "ou=people,dc=test,dc=de" subordinate rootdn "cn=admin,dc=test,dc=de" directory /tmp/ldap1/ index objectclass eq index cn eq database hdb suffix "dc=test,dc=de" rootdn "cn=admin,dc=test,dc=de" directory /tmp/ldap2/ index objectclass eq ------------------ Sample LDIF: ------------------ dn: ou=people,dc=test,dc=de objectclass: organizationalUnit ou: people ------------------ valgrind gives me this: ------------------ ==8742== Invalid write of size 4 ==8742== at 0x4C2856C: memset (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8742== by 0x50D396: bdb_tool_index_add (tools.c:556) ==8742== by 0x50D8E2: hdb_tool_entry_put (tools.c:653) ==8742== by 0x4D59DB: glue_tool_entry_put (backglue.c:1177) ==8742== by 0x4DBF55: slapadd (slapadd.c:347) ==8742== by 0x41CB3D: main (main.c:653) ==8742== Address 0x77d6c00 is 0 bytes after a block of size 16 alloc'd ==8742== at 0x4C2659D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8742== by 0x5098C85: ber_memalloc_x (memory.c:228) ==8742== by 0x469FE0: ch_malloc (ch_malloc.c:54) ==8742== by 0x50C16C: hdb_tool_entry_open (tools.c:139) ==8742== by 0x4D47E0: glue_tool_entry_open (backglue.c:758) ==8742== by 0x4DB598: slapadd (slapadd.c:116) ==8742== by 0x41CB3D: main (main.c:653) ==8742== ==8742== Invalid read of size 8 ==8742== at 0x555EEE: hdb_index_recrun (index.c:457) ==8742== by 0x50D4AF: bdb_tool_index_add (tools.c:577) ==8742== by 0x50D8E2: hdb_tool_entry_put (tools.c:653) ==8742== by 0x4D59DB: glue_tool_entry_put (backglue.c:1177) ==8742== by 0x4DBF55: slapadd (slapadd.c:347) ==8742== by 0x41CB3D: main (main.c:653) ==8742== Address 0x77d6c00 is 0 bytes after a block of size 16 alloc'd ==8742== at 0x4C2659D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8742== by 0x5098C85: ber_memalloc_x (memory.c:228) ==8742== by 0x469FE0: ch_malloc (ch_malloc.c:54) ==8742== by 0x50C16C: hdb_tool_entry_open (tools.c:139) ==8742== by 0x4D47E0: glue_tool_entry_open (backglue.c:758) ==8742== by 0x4DB598: slapadd (slapadd.c:116) ==8742== by 0x41CB3D: main (main.c:653) ==8742== ------------------ The reason for this seems to be that in a glued setup bdb_tool_entry_open() (back-bdb/tools.c) doesn't reallocate bdb_tool_index_rec correctly when called for the subordinate database. It is only allocated once, for the superior database and as that one has a smaller number of indexes (bdb->bi_nattrs), it is too small for the subordinate database. While debugging this I also noticed that there are some more problems with "slapadd -q" and glued bdb/hdb-databases. When the currenty entry needs to be added to a differnent database than the previous one, slapadd will close the current database (calling bdb_tool_entry_close()) and open the other database. In bdb_tool_entry_close() however slapd_shutdown will be set, which will cause the indexing tasks to immediately shutdown the next time they run. So from that point on the indexing tasks will not run correctly anymore (even for the new opened database).

1 0

Re: (ITS#6792) rwm with broken config suppresses LDAP response
by masarati＠aero.polimi.it 17 Jan '11

17 Jan '11

masarati(a)aero.polimi.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: RE24, HEAD >> OS: Linux x86_64 >> URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt >> Submission from: (NULL) (193.157.201.147) >> Submitted by: hallvard >> >> >> rwm suppresses the LDAP response message if rwm_response() fails. >> This hangs waiting for the response: >> >> include servers/slapd/schema/core.schema >> database monitor >> overlay rwm >> rwm-rewriteEngine on >> rwm-rewriteContext matchedDN >> # Rewrite to nonexistent $1 or broken DN >> rwm-rewriteRule ".*time.*" "cn=test,$1" : >> rwm-rewriteRule ".*" "urgle" : >> >> ldapcompare -x cn=hello,cn=time,cn=monitor l:x >> ldapsearch -xLLL -b cn=hello,cn=monitor >> >> The enclosed patch seems to fix it, but I've only looked briefly at >> what's going on. > > Good catch; however, the problem might need a slightly different fix; in > fact, yours prevents rwm_response from aborting the operation by forcing > an "unwilling to perform" based on the contents of the referral/matched. Sorry, I misread your patch; in fact, it's about setting sr_err as appropriate while letting the progess go on to the following hanlder, so it is correct to always return SLAP_CB_CONTINUE while eventually setting sr_err if needed by the rewrite engine. p.

1 0

Re: (ITS#6792) rwm with broken config suppresses LDAP response
by hyc＠symas.com 17 Jan '11

17 Jan '11

masarati(a)aero.polimi.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: RE24, HEAD >> OS: Linux x86_64 >> URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt >> Submission from: (NULL) (193.157.201.147) >> Submitted by: hallvard >> >> >> rwm suppresses the LDAP response message if rwm_response() fails. >> This hangs waiting for the response: >> >> include servers/slapd/schema/core.schema >> database monitor >> overlay rwm >> rwm-rewriteEngine on >> rwm-rewriteContext matchedDN >> # Rewrite to nonexistent $1 or broken DN >> rwm-rewriteRule ".*time.*" "cn=test,$1" : >> rwm-rewriteRule ".*" "urgle" : >> >> ldapcompare -x cn=hello,cn=time,cn=monitor l:x >> ldapsearch -xLLL -b cn=hello,cn=monitor >> >> The enclosed patch seems to fix it, but I've only looked briefly at >> what's going on. > > Good catch; however, the problem might need a slightly different fix; in > fact, yours prevents rwm_response from aborting the operation by forcing > an "unwilling to perform" based on the contents of the referral/matched. > > However, this is probably conflicting (as in many other cases in > slapo-rwm(5)), with the fact that some operations (e.g. extended) do not > return response directly, but delegate the frontend; or, like the bind > operation, only return unsuccessful results directly, and delegate > successful responses to the frontend. Perhaps this ITS could serve as a reminder to remove those two inconsistencies from the structure of this code. The historical reasons for Bind's behavior no longer apply. I don't believe there was ever any special reason why exops needed to behave this way. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6792) rwm with broken config suppresses LDAP response
by masarati＠aero.polimi.it 17 Jan '11

17 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE24, HEAD > OS: Linux x86_64 > URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt > Submission from: (NULL) (193.157.201.147) > Submitted by: hallvard > > > rwm suppresses the LDAP response message if rwm_response() fails. > This hangs waiting for the response: > > include servers/slapd/schema/core.schema > database monitor > overlay rwm > rwm-rewriteEngine on > rwm-rewriteContext matchedDN > # Rewrite to nonexistent $1 or broken DN > rwm-rewriteRule ".*time.*" "cn=test,$1" : > rwm-rewriteRule ".*" "urgle" : > > ldapcompare -x cn=hello,cn=time,cn=monitor l:x > ldapsearch -xLLL -b cn=hello,cn=monitor > > The enclosed patch seems to fix it, but I've only looked briefly at > what's going on. Good catch; however, the problem might need a slightly different fix; in fact, yours prevents rwm_response from aborting the operation by forcing an "unwilling to perform" based on the contents of the referral/matched. However, this is probably conflicting (as in many other cases in slapo-rwm(5)), with the fact that some operations (e.g. extended) do not return response directly, but delegate the frontend; or, like the bind operation, only return unsuccessful results directly, and delegate successful responses to the frontend. p.

1 0

(ITS#6793) Bad free in back-ldap when matchedDN changes
by h.b.furuseth＠usit.uio.no 17 Jan '11

17 Jan '11

Full_Name: Hallvard B Furuseth Version: RE24, HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_back_search() can free rs->sr_matched after sending it. That breaks if something replaced rs->sr_matched during send_ldap_result(). Fixing to keep the matchedDN to free in a local variable. (Could have used REP_MATCHED_MUSTBEFREED, but might as well keep the logic which tracks whether or not the value has a memory context.) Also removing 'save_matched', cleaned up by result.c 1.313 (ITS#5340): /* FIXME: shouldn't this be null? */ const char *save_matched = rs->sr_matched; Yes, it should be null. Is it not, preserving it isn't helpful anyway. To force a predictable matchedDN crash, let e.g. valsort produce an unfreeable matchedDN: Index: servers/slapd/overlays/valsort.c @@ -274,2 +274,7 @@ valsort_response( Operation *op, SlapReply *rs ) + if ( rs->sr_matched ) { + rs->sr_matched = "cn=bang"; + rs->sr_flags &= ~REP_MATCHED_MASK; /* do not free it */ + } + /* If this is not a search response, or it is a syncrepl response, Then provoke a matchedDN from the "remote" slapd and feed it to valsort: slapd -d0 -h ldap://localhost:3890/ -f <config below> database monitor database ldap suffix cn=foo uri ldap://localhost:3890/ overlay valsort overlay rwm rwm-suffixmassage cn=foo cn=monitor ldapsearch -xh localhost:3890 -b cn=hello,cn=foo

1 0

(ITS#6792) rwm with broken config suppresses LDAP response
by h.b.furuseth＠usit.uio.no 17 Jan '11

17 Jan '11

Full_Name: Hallvard B Furuseth Version: RE24, HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt Submission from: (NULL) (193.157.201.147) Submitted by: hallvard rwm suppresses the LDAP response message if rwm_response() fails. This hangs waiting for the response: include servers/slapd/schema/core.schema database monitor overlay rwm rwm-rewriteEngine on rwm-rewriteContext matchedDN # Rewrite to nonexistent $1 or broken DN rwm-rewriteRule ".*time.*" "cn=test,$1" : rwm-rewriteRule ".*" "urgle" : ldapcompare -x cn=hello,cn=time,cn=monitor l:x ldapsearch -xLLL -b cn=hello,cn=monitor The enclosed patch seems to fix it, but I've only looked briefly at what's going on.

1 0

(ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by rmeggins＠redhat.com 14 Jan '11

14 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-cert-verify-uses-incorrect-… Submission from: (NULL) (76.113.111.209) The cert verify routines were using type SECCertUsage instead of type SECCertificateUsage. The values are similar, and this was causing verify errors of SEC_ERROR_INADEQUATE_KEY_USAGE and SEC_ERROR_INADEQUATE_CERT_TYPE. MozNSS only checks the usage if the cert includes the usage extensions which is why I didn't see this error earlier. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs