openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

(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

(ITS#6790) Patch - Mozilla NSS - fix default cipher suite list
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-fix-default-cipher-suite-li… Submission from: (NULL) (76.113.111.209) If no TLS cipher suites are specified, the list of default cipher suites used with moznss is somewhat lacking. This patch makes tls_m use the "DEFAULT" list, and adds more cipher suites to the default list. 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

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 14 Jan '11

14 Jan '11

Rein Tollevik wrote: > On 13.01.11 21.31, hyc(a)symas.com wrote: >> cmikk(a)qwest.net wrote: >>> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: >>>> On 11/19/10 23:55 , cmikk(a)qwest.net wrote: >>>> >>>>> will evaluate to true in cases where it should not. A quick fix would be to >>>>> compare directly against the CSN of the sessionlog's head: >>>> >>>> An extended version of this fix, which also ensures that the >>>> sessionlog is kept in csn order, is now in head. Please test, >>>> syncprov.c revision 1.320. >>> >>> Looks good to me. Thank you. >>> >>> I discovered this bug while trying to reproduce ITS#6717. >>> >>> I've attached a patch to that ITS which appears to fix >>> that problem. If you have the time, I'd appreciate some >>> feedback on that patch. The issue makes it very inefficient >>> to run a slave in refreshOnly mode with a multimaster / >>> mirrormode master. >>> >>> Best Regards, >> >> The current code is broken. > > Which current code? My patch for this its, or his patch for its#6717? We're only talking about this specific ITS here, and that comment applied to the ITS before my last patch. I reopened the ITS, patched again, and then marked it Test again. >>> Other than the patch I suggested (using the list head's >>> CSN value directly), I can think of two other approaches: >>> >>> 1) When adding an entry to the sessionlog, check >>> if sl_mincsn is empty. If it is, update sl_mincsn >>> to the new entry's CSN. >>> >>> 2) When initializing the sessionlog, set sl_mincsn >>> to the maximum contextCSN value of the underlying >>> database. >>> >>> #2 seems ideal from an efficiency standpoint, although it >>> differs from the algorithm the current code appears to be >>> intended to implement. >> >> We should have gone with #2. The problem scenario: >> >> 1: Provider and consumer in sync, both started fresh, sessionlog is empty. >> 2: stop consumer >> 3: write on provider >> 4: start consumer >> >> Result: the sessionlog is ignored, because the sl_head is newer than the >> consumer's cookie. >> >> After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog >> is used from then on. > > Initializing sl_mincsn from the maximum csn won't do much good here, as > long as the (current) requirement to use the log is that the consumers > mincsn is greater or equal to sl_mincsn. Assuming there is more than > one csn in the set that is.. > Initializing with the minimum csn should cause the current log to be > used in this scenario. But, if the provider restarts between 3 and 4 it > would incorrectly appear that replaying the log would be sufficient to > bring the consumer in sync. A situation far worse than doing a refresh > when replaying the log would have been sufficient. Which is why I chose the maximum CSN. It will work fine in most cases. In the rare cases where it doesn't work, the log will be ignored and no harm is done. I.e., when writes are always received in order, the max CSN is the only one that matters. > More on possible fixes in my reply to your other message. > > Rein > -- -- 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

← Newer
1
...
7
8
9
10
11
12
13
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011