- openldap-bugs - openldap.org

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 15 Jan '11

15 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 15 Jan '11

15 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

(ITS#6788) Only one reference when ldap_open_internal_connection
by jgiesl＠monetplus.cz 14 Jan '11

14 Jan '11

Full_Name: Jiri Giesl Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.111.5.220) We tried to estalish connection to LDAP server by our own (because of proxy usage) and then use "ldap_open_internal_connection" function to initialize internal structures of openldap. After successful SASL binding we realized that the connection to LDAP server has been closed. We found out that there is checking for reference count in "wait4msg" function (result.c file) this way: if ( lc->lconn_refcnt <= 1 ) During classic initialization and SASL binding we get 2 references, however when using "ldap_open_internal_connection" and SASL binding we get only 1 reference. We realized that in "ldap_open_defconn" (function which is called for establishing of a new connection) there is reference counter which is increased this way: ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ When we added this incrementation also into "ldap_open_internal_connection" (open.c file), everything goes well (it is obvious). Are we wrong or this is really minor bug (missing incrementation of reference counter in "ldap_open_internal_connection")?

1 0

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

13 Jan '11

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. 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. > There might still be a theoretical problem there, if the sid of an entry > in the log is not in the set sent by the consumer. But since we know > they have the same number of CSNs this can only happen during initial > setup of a multi-master configuration. In which case the admins real > problem is that he didn't bring the servers online in a controlled order.. > > 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 hyc＠symas.com 13 Jan '11

13 Jan '11

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. > 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. -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 13 Jan '11

13 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > BTW, why do CSN times have 6-decimal precision when we only care > about 1/256 second? Or doesn't it matter if this test is gives > false positives for small time differences? > Yeah, we really just don't care. 6-decimal precision is for conflict resolution, this is just to determine if something is "new enough" where "enough" doesn't need to be exact. -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

BTW, why do CSN times have 6-decimal precision when we only care about 1/256 second? Or doesn't it matter if this test is gives false positives for small time differences? -- Hallvard

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

hyc(a)symas.com writes: > I guess that's a fair point, but operating without an entryCSN index would be > a config mistake anyway. (Note that the unchecked limit only has relevance on > backends that support indexing in the first place.) As a user that's a config mistake from which I'd expect poor performance or sizelimit warnings in syslog, not broken CSN handling. In particular when slapo-syncprov(5) does mention indexing without demanding it: "On databases that support inequality indexing, it is helpful to set an eq index on the entryCSN attribute when using this overlay." -- Hallvard

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 13 Jan '11

13 Jan '11

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be >> SizeLimitExceeded (or TimeLimitExceeded). > > Okay. Took me some digging to see that. Anyway, the main problem is > that hitting the unchecked limit does not imply there is an entry which > even approximately matches the filter. Not without indexes. > I guess that's a fair point, but operating without an entryCSN index would be a config mistake anyway. (Note that the unchecked limit only has relevance on backends that support indexing in the first place.) -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

hyc(a)symas.com writes: > Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be > SizeLimitExceeded (or TimeLimitExceeded). Okay. Took me some digging to see that. Anyway, the main problem is that hitting the unchecked limit does not imply there is an entry which even approximately matches the filter. Not without indexes. -- Hallvard

1 0

(ITS#6787) back-monitor cache locking problem
by hyc＠OpenLDAP.org 13 Jan '11

13 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc As noted on http://www.openldap.org/lists/openldap-devel/201101/msg00033.html back-monitor hangs in test036 (and maybe test039) because it keeps a cached entry locked while sending to the client. It should be releasing the locks before sending the entry. A fix is coming.

1 0

Re: (ITS#6783) back-monitor cache/mutex problem
by hyc＠symas.com 12 Jan '11

12 Jan '11

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux x86_64 >> URL: >> Submission from: (NULL) (193.157.198.89) >> Submitted by: hallvard >> >> >> Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: >> >> ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); > > I see this too. The Abandon loop's logic is backwards. It's looping from the > current entry to the end of the list and releasing those entries, when it > should only be reasling from the head of the list to the current entry. (I.e., > everything on the tail of the list has not yet been locked by this thread.) > > I'll commit a fix shortly. Never mind, I read this loop wrong. The actual problem is that it calls monitor_cache_release() for volatile entries that had never been locked, and it enters the nonvolatile == 0 loop even when there were no volatile entries. -- -- 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#6783) back-monitor cache/mutex problem
by hyc＠symas.com 12 Jan '11

12 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (193.157.198.89) > Submitted by: hallvard > > > Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: > > ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); I see this too. The Abandon loop's logic is backwards. It's looping from the current entry to the end of the list and releasing those entries, when it should only be reasling from the head of the list to the current entry. (I.e., everything on the tail of the list has not yet been locked by this thread.) I'll commit a fix shortly. > > #2 ldap_pvt_thread_mutex_unlock (mutex=0x1a526c0) at thr_debug.c:1031 > #3 monitor_cache_release (mi=0x92c8c0, e=0x19ec7f8) at cache.c:389 > #4 monitor_send_children (op=0x236bcb0, rs=0x7f54ce4eea40, > e_parent=0x19ec758, sub=1) at search.c:97 > #5 monitor_back_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:245 > #6 fe_op_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:372 > > That's the o_abandon branch in monitor_send_children(). > > I copied the loop out of the o_abandon branch. test036 crashed with > what I assume is the same problem. No need to hit ^C at the right time: > > Index: back-monitor/search.c > @@ -89,2 +89,9 @@ monitor_send_children( > > + if ( nonvolatile == 0&& (e_tmp = e) != NULL ) { > + do { > + mp = e_tmp->e_private; > + LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER(&mp->mp_mutex ); > + } while ( (e_tmp = mp->mp_next)&& e_tmp != e_nonvolatile ); > + } > + > if ( op->o_abandon ) { > > There is a similar loop further down, I didn't look at that one. > > Variables at the crash: > > e == e_nonvolatile > e_tmp == ((monitor_entry_t *) e->e_private)->mp_next > > *(monitor_entry_t *) e->e_private == { > mp_mutex = {...}, mp_next = 0x261b2a8, mp_children = 0x261b668, > mp_info = 0x8f21c0, mp_flags = 32, mp_cb = 0x0 > } > > *(monitor_entry_t *) e_tmp->e_private == { > mp_mutex = {...}, mp_next = 0x261b2f8, mp_children = 0x261ba28, > mp_info = 0x8f2258, mp_flags = 128, mp_cb = 0x0 > } > > -- -- 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

ITS#6786
by masarati＠aero.polimi.it 12 Jan '11

12 Jan '11

There is no evidence in your report of a software error, it is likely a user error. Moreover, OpenLDAP 2.2.23 was discontinued more than 5 years ago; the current release is 2.4.23. Please update and direct software usage questions to openldap-technical(a)openldap.org. This ITS will be closed. p.

1 0

(ITS#6786) OpenLdap 2.2.29 Support for Windows Server 2008
by praveen_kumar.thirunavukkarasu＠alcatel-lucent.com 12 Jan '11

12 Jan '11

Full_Name: Praveen Kumar Version: 2.2.29 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.168.34) We are using openldap 2.2.29 in our application. It is bundled with our application and is installed with our product installation. Installation of openldap goes smooth and service gets started. But when performing ldapdelete or ldapadd operation the process fails. The logs shows as ldap_bind: Can't contact LDAP server (-1) Not sure if this is because of some security issue when installing in Windows Server 2008. Kindly help me regarding the same and let me know if I need to modify some security setting with Windows. Thanks, Praveen.

1 0

Re: (ITS#6784) Spurious mutex unlock in authzid.c
by masarati＠aero.polimi.it 12 Jan '11

12 Jan '11

Cruft unintentionally left over; fixed in HEAD, thanks. p.

1 0

(ITS#6785) slapo-chain mishandles sr_text/sr_matched
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard ldap_chain_response() can send sr_text/sr_matched which refers to a different error than sr_err and rc. It saves rs-> sr_err, sr_text, sr_matched to three local variables and can restore them later, but not maintain the text and matched variables in parallel with err. Also it does not track/reset/obey REP_MATCHED_MUSTBEFREED along with sr_matched. Fails test032-chain with the asserts below. However there may be non-success result with the wrong text/matched too, that cannot be assert()ed. Come to think of it, maybe the last issues applies to ITS#6774 too? REP_MATCHED_MUSTBEFREED, mismatch between failure code and text/matched. Index: servers/slapd/back-ldap/chain.c @@ -1019,4 +1019,14 @@ ldap_chain_response( Operation *op, SlapReply *rs ) rs->sr_ref = NULL; + const char *bad_incoming_matched = NULL, *bad_incoming_text = NULL; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + bad_incoming_matched = matched; + case LDAP_REFERRAL: + bad_incoming_text = text; + } + /* we need this to know if back-ldap returned any result */ lb.lb_lc = lc; @@ -1169,4 +1179,15 @@ cannot_chain:; dont_chain:; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + assert( !matched || bad_incoming_matched ); + case LDAP_REFERRAL: + assert( !text || bad_incoming_text ); + } + assert( rc != LDAP_SUCCESS || + (( !text || bad_incoming_text) && + ( !matched || bad_incoming_matched ))); rs->sr_err = sr_err; rs->sr_type = sr_type;

1 0

(ITS#6784) Spurious mutex unlock in authzid.c
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard authzid_conn_find() in contrib/slapd-modules/authzid/authzid.c can do ldap_pvt_thread_mutex_unlock( &authzid_mutex ); even though every code path from ldap_pvt_thread_mutex_lock( &authzid_mutex ); elsewhere in authzid.c leads to an unlock statement of its own.

1 0

(ITS#6783) back-monitor cache/mutex problem
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); #2 ldap_pvt_thread_mutex_unlock (mutex=0x1a526c0) at thr_debug.c:1031 #3 monitor_cache_release (mi=0x92c8c0, e=0x19ec7f8) at cache.c:389 #4 monitor_send_children (op=0x236bcb0, rs=0x7f54ce4eea40, e_parent=0x19ec758, sub=1) at search.c:97 #5 monitor_back_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:245 #6 fe_op_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:372 That's the o_abandon branch in monitor_send_children(). I copied the loop out of the o_abandon branch. test036 crashed with what I assume is the same problem. No need to hit ^C at the right time: Index: back-monitor/search.c @@ -89,2 +89,9 @@ monitor_send_children( + if ( nonvolatile == 0 && (e_tmp = e) != NULL ) { + do { + mp = e_tmp->e_private; + LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER( &mp->mp_mutex ); + } while ( (e_tmp = mp->mp_next) && e_tmp != e_nonvolatile ); + } + if ( op->o_abandon ) { There is a similar loop further down, I didn't look at that one. Variables at the crash: e == e_nonvolatile e_tmp == ((monitor_entry_t *) e->e_private)->mp_next *(monitor_entry_t *) e->e_private == { mp_mutex = {...}, mp_next = 0x261b2a8, mp_children = 0x261b668, mp_info = 0x8f21c0, mp_flags = 32, mp_cb = 0x0 } *(monitor_entry_t *) e_tmp->e_private == { mp_mutex = {...}, mp_next = 0x261b2f8, mp_children = 0x261ba28, mp_info = 0x8f2258, mp_flags = 128, mp_cb = 0x0 }

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 11 Jan '11

11 Jan '11

Hallvard B Furuseth wrote: > Reopening this ITS... > > Howard Chu writes: >>> Full_Name: Hallvard B Furuseth >>> >>> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. >>> findcsn_cb() says >>> /* We just want to know that at least one exists, so it's OK if >>> * we exceed the unchecked limit or size limit. >>> */ >>> >>> This looks like it can return a false positive if two or more other >>> entries which the filter would eliminate have the same hash as the >>> value syncprov searches for. >> >> I don't believe this can cause any problem though. CSN indexing doesn't use a >> hash the way other indices do; the CSN timestamp is converted to binary form >> and saved as a 40 bit integer. Index collisions will only occur for multiple >> changes that occurred within the same 1-second interval. > > Only if entryCSN is indexed, which is recommended but not required in > man slapo-syncprov. With un-indexed entryCSN it'll hit the unchecked > limit if there are two or more entries in scope for the search. > > Also - another marginal case - findcsn_cb() assumes adminLimitExceeded > implies a size limit (.size or .unchecked). It could also mean a hard > time limit. After someone did ^Z on slapd while stepping through some > debugging, if nothing else. Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be SizeLimitExceeded (or TimeLimitExceeded). -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 11 Jan '11

11 Jan '11

Reopening this ITS... Howard Chu writes: >> Full_Name: Hallvard B Furuseth >> >> overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. >> findcsn_cb() says >> /* We just want to know that at least one exists, so it's OK if >> * we exceed the unchecked limit or size limit. >> */ >> >> This looks like it can return a false positive if two or more other >> entries which the filter would eliminate have the same hash as the >> value syncprov searches for. > > I don't believe this can cause any problem though. CSN indexing doesn't use a > hash the way other indices do; the CSN timestamp is converted to binary form > and saved as a 40 bit integer. Index collisions will only occur for multiple > changes that occurred within the same 1-second interval. Only if entryCSN is indexed, which is recommended but not required in man slapo-syncprov. With un-indexed entryCSN it'll hit the unchecked limit if there are two or more entries in scope for the search. Also - another marginal case - findcsn_cb() assumes adminLimitExceeded implies a size limit (.size or .unchecked). It could also mean a hard time limit. After someone did ^Z on slapd while stepping through some debugging, if nothing else. -- Hallvard

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 11 Jan '11

11 Jan '11

On Mon, Jan 10, 2011 at 11:48:37AM -0800, Howard Chu wrote: > >No problem. I propose the following to bring the docs in line with > >behaviour. > > This looks a bit too specific, the olcSaslRealm setting affects > other SASL mechanisms too. True, although this text is under the GSSAPI subheading so I would read it as specific to the GSSAPI mechanism. > For GSSAPI it should probably just say > not to specify olcSaslRealm at all since the mechanism has its own > notion of realms already. If they are using a mixture of SASL mechanisms then they might need to set olcSaslRealm for the benefit of another one. How about this: ------------------------------------------------------------------- If you are using only GSSAPI authentication then you should not configure olcSaslRealm. If you do, then it is always inserted as an extra component in the authorization DN, regardless of the realm of the client. For example, if you set olcSaslRealm to {{EX:example.com}} then you will get: uid=kurt,cn=example.com,cn=gssapi,cn=auth uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth -------------------------------------------------------------------

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 10 Jan '11

10 Jan '11

Brian Candler wrote: > On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote: >> I don't believe we have any freedom to make any code changes here; >> feel free to suggest verbiage changes for the documentation. > > No problem. I propose the following to bring the docs in line with > behaviour. This looks a bit too specific, the olcSaslRealm setting affects other SASL mechanisms too. For GSSAPI it should probably just say not to specify olcSaslRealm at all since the mechanism has its own notion of realms already. Most likely you would only set this for something like DIGEST-MD5 which uses realms but doesn't inherently know its own realm name. > --- sasl.sdf.orig 2011-01-03 09:45:55.754879001 +0000 > +++ sasl.sdf 2011-01-03 10:07:34.808208000 +0000 > @@ -135,25 +135,35 @@ > For the purposes of authentication and authorization, {{slapd}}(8) > associates an authentication request DN of the form: > > -> uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth > +> uid=<primary[/instance][@realm]>,cn=gssapi,cn=auth > + > +The realm is omitted by Cyrus SASL if it's equal to the default realm of the > +server in {{FILE:/etc/krb5.conf}}. > > Continuing our example, a user with the Kerberos principal > {{EX:kurt@EXAMPLE.COM}} would have the associated DN: > > -> uid=kurt,cn=example.com,cn=gssapi,cn=auth > +> uid=kurt,cn=gssapi,cn=auth > > and the principal {{EX:ursula/admin@FOREIGN.REALM}} would have the > associated DN: > > -> uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > +> uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > > > -The authentication request DN can be used directly ACLs and > +The authentication request DN can be used directly in ACLs and > {{EX:groupOfNames}} "member" attributes, since it is of legitimate > LDAP DN format. Or alternatively, the authentication DN could be > mapped before use. See the section {{SECT:Mapping Authentication > Identities}} for details. > > +If you configure olcSaslRealm then it is always inserted as an extra > +component in the authorization DN, regardless of the realm of the client. > +For example, if you set olcSaslRealm to {{EX:example.com}} then you will > +get: > + > +> uid=kurt,cn=example.com,cn=gssapi,cn=auth > +> uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth > > H3: KERBEROS_V4 > > -- -- 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#5350) Request: ITS links in mailinglist archives
by h.b.furuseth＠usit.uio.no 10 Jan '11

10 Jan '11

Kurt Zeilenga writes: > However, there may be an reasonable alternative suggestion. The ITS > software itself could be modified to include a URI to the issue in > each message it sends. This would not only show up in archives, but > in mail distributed to -bugs list and directly to users of the system. Yes, that would help. Won't affect the discussion lists, though. Except maybe people will start to quote the URLs more. -- Hallvard

1 0

Re: (ITS#6684)
by hyc＠symas.com 09 Jan '11

09 Jan '11

Norbert Püschel wrote: > Am 30.12.10 18:28, schrieb Howard Chu: >> norbert(a)pueschel.net wrote: >>> Updated TAR-file with (hopefully) sufficient copyright notice... >>> >>> http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar >> >> Your code does a string compare againset "memberOf" to detect those >> filter references. >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the >> memberof overlay, there's no guarantee that this is the correct >> attribute to be looking for. It should also be configurable in your >> patch. >> > You are right, of course. The problem is, I do not understand enough of > internal structures to find the correct pointer... I would need to > detect the memberof-overlay and find the correct string or pointer to > compare to. I will gladly do so if you can give me some hints where to look. AttributeDescriptions are a fundamental data structure used throughout the code. It would be impossible to have read any of the existing overlay code without encountering countless examples of their use. There is no need to detect the memberof overlay. All you need to do is provide a configuration option to specify the attribute you are going to treat as a memberof attribute. >> You're using strcasecmp, but your inputs are already normalized >> values. You should just use ber_bvcmp. >> > Right, see above. > >> Replying to the original: >> >>> 1) Using non-DN-valued URIs for autogroup does not work correctly, even >>> with the latest version from HEAD. Especially changing group member is >>> not tracked. >> >> I don't see why this should ever work or be supported. LDAP groups >> list DNs. >> > > Wrong. If you really think so, why did you accept Raphael Ouazana's > patch, which is all about making this case work? > Also see below. >>> 2) Using the memberOf-overlay for constructing autogroups does not work >> >> I don't see any reason why this should work. The memberof overlay is >> not used to construct groups, it is only used to report on group >> memberships that have already been defined. > Well, consider the following construction (which I am using in our ldap > directory and which is the reason I started work on the autogroup overlay): Ugh. > dn: cn=admins,ou=access,dc=networker-gmbh,dc=de > objectClass: groupOfNames > cn: admins > member: uid=xxxxx,ou=people,dc=networker-gmbh,dc=de > member: uid=yyyyyy,ou=people,dc=networker-gmbh,dc=de > > dn: cn=admins(a)networker-gmbh.de,ou=aliases,dc=networker-gmbh,dc=de > objectClass: nisMailAlias > objectClass: labeledURIObject > cn: admins(a)networker-gmbh.de > labeledURI: > ldap:///ou=people,dc=networker-gmbh,dc=de?mail?one?(&(objectClass=inetOrgPerson)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) > > dn: cn=admins,ou=groups,dc=networker-gmbh,dc=de > objectClass: posixGroup > objectClass: labeledURIObject > cn: admins > gidNumber: 10100 > labeledURI: > ldap:///ou=people,dc=networker-gmbh,dc=de?uid?one?(&(objectClass=posixAccount)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) > > Additionally, consider this relevant excerpt from slapd.conf: > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > dynlist-attrset nisMailAlias labeledURI rfc822MailMember:mail > > overlay autogroup > autogroup-attrset posixGroup labeledURI memberUid > > As you can see, I use memberOf the construct mail aliases and posix > group memberships from a groupOfNames master-list. For the mail aliases, > dyngroup is sufficient, but the posix groups also need reverse lookups, > which is why I'm using the autogroup overlay for this. Also, I cannot > use a dn-valued list for the posix groups, as the Solaris NSS-libraries > require the uid attribute to not contain a full dn. Short answer - use an NSS client that actually supports RFC2307bis, like every other vendor in the world already does. In the meantime, if you submit a cleaned up patch that makes better use of the slapd APIs, we can review it again. -- -- 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#5350) Request: ITS links in mailinglist archives
by Kurt Zeilenga 07 Jan '11

07 Jan '11

In short, no. The underlying archives are the email messages submitted to the list stored in mbox format, which are then reformatted to HTML using off-the-shelf software. While it technically possible to hack that software to do all kinds of reformatting (as we have the source), we don't have the resources to maintain a custom fork of that software. However, there may be an reasonable alternative suggestion. The ITS software itself could be modified to include a URI to the issue in each message it sends. This would not only show up in archives, but in mail distributed to -bugs list and directly to users of the system.

1 0

Re: (ITS#6578) Mailman subscribtion answer update
by Kurt Zeilenga 07 Jan '11

07 Jan '11

fixed. Thanks.

1 0

Re: (ITS#6750) About 3rd Party Technical Support Services
by Kurt Zeilenga 07 Jan '11

07 Jan '11

A listing has been added. Please check.

1 0

(ITS#6782) test049 breaks if an alternate testdir is set
by hyc＠OpenLDAP.org 07 Jan '11

07 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 If USER_TESTDIR is set to choose an alternate test directory, and syncprov is a module, the moduleload fails because it uses the wrong modulepath

1 0

(ITS#6781) Add support for suffixmassage in syncrepl consumer
by hyc＠OpenLDAP.org 06 Jan '11

06 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 (Already in HEAD/RE24) The consumer should be able to pull from a remote suffix that differs from the local suffix.

1 0

(ITS#6780) Add support for multiple listener threads
by hyc＠OpenLDAP.org 06 Jan '11

06 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 (Already in HEAD/RE24, just needs a manpage update)

1 0

(ITS#6779) Allow clients to specify USERNAME in session tracking control
by masarati＠aero.polimi.it 05 Jan '11

05 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A patch is coming. p.

1 0

(ITS#6778) One-time leak in generic client tools controls
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A fix is coming. p.

1 0

Re: (ITS#6777) test014 fails
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Sorry for the noise. The problem was real (the leak), but the solution (that free) was wrong. It's not a big deal: we usually tolerate leaks in client tools (they're mainly annoying because they cause a lot of noise in valgrind output). I'll provide a better fix some time. p.

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:30 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 1/4/2011 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> The ldapwhoami utility was recently modified to use ldap_parse_whoami. >> This change appears to have broken test014: > > This isn't ldapwhoami of course, but a library issue. :/ Modified Files: common.c 1.143 -> 1.144 Fixes it, thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 1/4/2011 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The ldapwhoami utility was recently modified to use ldap_parse_whoami. > This change appears to have broken test014: This isn't ldapwhoami of course, but a library issue. :/ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6777) test014 fails
by quanah＠OpenLDAP.org 04 Jan '11

04 Jan '11

Full_Name: Quanah Gibson-Mount Version: RE24 1/4/2011 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The ldapwhoami utility was recently modified to use ldap_parse_whoami. This change appears to have broken test014: Testing ldapwhoami as cn=Manager,dc=example,dc=com for dn:cn=Barbara Jensen,ou=Information Technology DivisioN,ou=People,dc=example,dc=com... ldap_parse_result: Proxied Authorization Denied (123) additional info: authzId mapping failed Result: Proxied Authorization Denied (123) Additional info: authzId mapping failed ldapwhoami failed (1)! Something seems seriously wrong with how it is parsing/passed the controls: <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 ==> hdb_bind: dn: cn=Manager,dc=example,dc=com conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=Manager,dc=example,dc=com" to "cn=Manager,dc=example,dc=com" send_ldap_result: conn=1004 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 conn=1004 op=0 RESULT tag=97 err=0 text= connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next ber_get_next: tag 0x30 len 76 contents: op tag 0x77, time 1294175708 ber_get_next conn=1004 op=1 do_extended ber_scanf fmt ({m) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (b) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) parseProxyAuthz: conn 1004 authzid="dn:cn=Ba<80><90>x" slap_sasl_getdn: conn 1004 id=dn:cn=Ba<80><90>x [len=11] >>> dnNormalize: <cn=Ba<80><90>x> => ldap_bv2dn(cn=Ba<80><90>x,0) <= ldap_bv2dn(cn=Ba<80><90>x)=0 <= get_ctrls: n=1 rc=123 err="authzId mapping failed" send_ldap_result: conn=1004 op=1 p=3 send_ldap_result: err=123 matched="" text="authzId mapping failed" send_ldap_response: msgid=2 tag=120 err=123 ber_flush2: 36 bytes to sd 12 conn=1004 op=1 RESULT tag=120 err=123 text=authzId mapping failed conn=1004 op=1 do_extended: get_ctrls failed connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next

1 0

Re: (ITS#6773) Per-connection extra stuff
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> I think we can live without this feature. E.g., ppolicy, sssvlv etc. all > just > create their own private arrays of per-conn structures. Sharing here will > require introducing another mutex. Right, I've fixed things differently. I note that other code (e.g. paged results) is write-accessing its state without mutex protection; although it is unlikely that more than one search operation use paged response concurrently, this is incorrect in principle. I'm closing this ITS. p.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by hyc＠symas.com 04 Jan '11

04 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > I've fixed it in HEAD, unless early errors in translucent_search() > should be ignored Patch looks OK, the remote server is authoritative so the first search must not fail. > or filter errors should NOT be ignored. Looks OK; as with any search if the filter doesn't match there should not be any entry returned. -- -- 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#6773) Per-connection extra stuff
by hyc＠symas.com 04 Jan '11

04 Jan '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it writes: >>> Unless there are objections, I'd commit it. >> >> Well, it breaks binary compatibility, but perhaps that'll break anyway? >> That is, will overlays/modules compiled with 2.4.23 break with slapd >> 2.4.24 or vice versa? > > No it won't, since I do not expect this to be released with 2.4.24 (nor > with 2.4). > > In general, yes, it will break binary compatibility, but it won't break > source code compatibility; eventuallysource code might if I move paged > results and so under the ConnExtra umbrella, which is not something I'm > struggling for at the moment. I think we can live without this feature. E.g., ppolicy, sssvlv etc. all just create their own private arrays of per-conn structures. Sharing here will require introducing another mutex. -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 04 Jan '11

04 Jan '11

In addition to the issues listed in my last message, this ITS depends on these: - ITS#6763: slapd does not clear sr_entry/ctrls on sizelimit/busy - ITS#6776: Control handling in PassMod exop + ppolicy - ITS#6760: rwm broken entry handling ==== Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> * hyc, please have a look at slapd/bconfig.c 1.419. If I have >> gotten things wrong, that one summarizes my mistakes nicely:-) I meant to say "If I've broken anything, that commit should summarize my worst mistakes." At least that worry is out of the way: > I think you're over-paranoid. config_build_entry() is only called by > internal plumbing and the SlapReply here never gets sent to > send_ldap_result(). It's only passed in because be_add() expects one; > the contents are mostly irrelevant. (Aside from rs_err) Thanks. Not exactly what I hoped to hear, but I did ask... I can revert it, or since this SlapReply is so uninteresting, maybe allow rs = NULL in this case so some callers can omit it. ==== Summary of changes: * Add rs_assert_*(), disabled by default, to check SlapReply state. * Majority of changes: Avoid reusing SlapReply: Reinitialize these variables at need with rs_reinit() or move a declaration inwards (typically into loops). I think I introduced 2 new SlapReply's, in bconfig.c (unnecessarily as Howards says) ad in pcache. * Use the rs_*() functions in result.c to manage SlapReply entries, rather than freeing/releasing by hand and every so often forgetting to handle some of the REP_ENTRY_* flags. This also makes slapd more aggressive about freeing entries. E.g. result.c _released_ entries at need before sending, so entry locks for cached entries would not wait for network traffic. OTOH it did not at that point bother with entries that merely needed _freeing_. * "Reset dangerous REP_ENTRY_* flags." This is so when a module puts e.g. puts Extended Operation data in the SlapReply, another module won't try to entry_free/release() that non-entry because of some leftover REP_ENTRY_* flags. This may have been over-paranoid too: I seem closer to having rs.<sr_type, sr_un> behave like a variant record where rs.sr_type actually can be trusted. Anyway, this paranoia shouldn't hurt. Others are some minor cleanups: * Reset some SlapReply flags & data. Reset data more consistenlty. (E.g. rs_entry and flags go together, so don't reset just entry.) * Clear out or avoid filling in known unwanted info (Don't set sr_err = non-success before entering an operation handler, do not set sr_text with sr_err = LDAP_SUCCESS, etc.) * Add an error check or two (was actually done for consistency sr_err vs sr_text) * slap.h: Cast REP_* #defines to slap_mask_t * No-op changes (remove lint, rearrange/simplify code a bit, etc) -- Hallvard

1 0

Re: (ITS#6769) Slapd fails to start when olcDbURI attribute is used
by jwinius＠umrk.nl 04 Jan '11

04 Jan '11

Quoting Quanah Gibson-Mount <quanah(a)zimbra.com>: > Your information is out of date. The patch was committed last November. Excellent! At least we now know that this bug has been taken care of. Thanks, Jaap

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs