openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 14 Jan '11

14 Jan '11

On 13.01.11 21.48, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >>> I think the best (blind) fix consists in only performing that test if >>> sl_mincsn is assigned a value; something like >> >> I'm looking at an extended fix. The problem with the current >> implementation is that is assumes the entries arrives in CSN order, >> which isn't necessarily true in a MMR configuration. >> >> My fix drops sl_mincsn, keeps the log queue in CSN order and compares >> with the head entry. It also wipes the log if it receives any changes >> without CSN (i.e during refresh). > > I'm not sure this latter is a good idea, in an MMR setup. In that case, we > should ensure that only CSNs matching the current SID are added to the log, > and we should always leave the log intact. I.e., the server is always > authoritative about its own writes. That implies that all servers must be interconnected in order to sync, which is a requirement I really hope nor think you want to introduce.. In any properly configured setup where the sessionlog is used I assume it is used on all the servers, and that the log is large enough to hold all changes occurring during reasonable consumer downtimes. In which case there will rarely be any refresh phases and wiping of the queue. My fix was more concerned with ensuring that replaying the log gave a correct synchronization than to use it in all possible cases. > But this kind of begs the question of whether the log should actually maintain > N mincsns, one for each known SID, the same way we do now for contextCSN. Yes, I've been wondering about that I too. I'm inclined to say that all entries in the log should hold the entire csn set as if was when the entry was added. The log could be initialized with an empty log entry holding the startup csn set, and kept in change fifo order. Mods without csn (i.e refresh mods) could then be stored on the log as well. But once one of them reaches the head of the list and gets removed then the list must be truncated up to the point where all remaining entries have a csn. The log should be reinitialized with the current csn set if the truncation caused it to end up empty. New consumers can replay the log if they present a csn set greater or equal to the set at the head of the log list. Rein

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 14 Jan '11

14 Jan '11

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? >> 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. More on possible fixes in my reply to your other message. Rein

1 0

(ITS#6789)
by sgallagh＠redhat.com 14 Jan '11

14 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just determined that this didn't occur on openldap-2.4.21, (on that version, we properly get a lot of useful information about why the connection failed). This leads me to believe that this issue is likely related to the recent switch to Mozilla NSS for crypto support. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wTkYACgkQeiVVYja6o6OFTQCeK7qYIw3754PfDolxkcld/D/B CpoAn0ubzxgg3ekr7Ik1SydV9NkS36ln =r+Ff -----END PGP SIGNATURE-----

1 0

(ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by sgallagh＠redhat.com 14 Jan '11

14 Jan '11

Full_Name: Stephen Gallagher Version: openldap-2.4.23 OS: Fedora 14 x86_64 URL: https://fedorahosted.org/sssd/ticket/699 Submission from: (NULL) (98.110.239.235) We have this code in the SSSD (which uses the openldap shared libraries for LDAP communication). ret = ldap_install_tls(state->sh->ldap); if (ret != LDAP_SUCCESS) { optret = ldap_get_option(state->sh->ldap, SDAP_DIAGNOSTIC_MESSAGE, (void*)&tlserr); if (optret == LDAP_SUCCESS) { DEBUG(3, ("ldap_install_tls failed: [%s] [%s]\n", ldap_err2string(ret), tlserr)); sss_log(SSS_LOG_ERR, "Could not start TLS encryption. %s", tlserr); ldap_memfree(tlserr); } else { DEBUG(3, ("ldap_install_tls failed: [%s]\n", ldap_err2string(ret))); sss_log(SSS_LOG_ERR, "Could not start TLS encryption. " "Check for certificate issues."); } However, whenever there is an issue (such as an invalid/expired certificate) our logs read: (Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [(null)] This means that the ldap_get_option(SDAP_DIAGNOSTIC_MESSAGE) is returning LDAP_SUCCESS, but the returned message is "(null)". This is not the same behavior as with an LDAPS connection, where it will in fact return a message indicating what certificate error was.

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