- openldap-bugs - openldap.org

Re: (ITS#6796) overlay proxycache
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Varnakov Kiril > Version: openldap-sasl-server-2.4.23 > OS: FreeBSD 8.0-RELEASE-p3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.235.170.154) > > > Hi. When i configure ldap server with overlay proxycache and set > pcachePersist=TRUE, only positive answer stay in cache after restart proxy > ldap. > If not restart proxy ldap, all good, negative answer in cache stay. Why? > > proxyTemplate (target=) 0 18400 18400 Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) and report. Please also note that while tracking this issue I also spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 -> 1.218). p.

1 0

(ITS#6797) Misc issues related to "pcachePersist"
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.31.111) Submitted by: ando found while tracking ITS#6796, not strictly related. A fix is coming. p.

1 0

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

18 Jan '11

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

1 0

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

18 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

17 Jan '11

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

1 0

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

14 Jan '11

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

1 0

(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

(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 12 Jan '11

12 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 10 Jan '11

10 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 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 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

(ITS#6776) Control handling in PassMod exop + ppolicy
by h.b.furuseth＠usit.uio.no 04 Jan '11

04 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.201.41) Submitted by: hallvard passwd_extop(op, rs) does an internal op->o_bd->be_modify(op, rs) and then intentionally returns with sr_text, sr_ref, sr_ctrls from be_modify intact, so the caller can send them. By my understanding this is quite fragile, since these SlapReply values can be invalid/out of scope after be_modify returns. It clashes with SlapReply cleanup effort, ITS#6758. It does this so ppolicy can insert its controls there, after detecting that the current be->be_modify call is actually a Password Modify exop. Maybe passwd_extop() instead can give the Modify a response or cleanup handler which steals any controls from the SlapReply, and reinserts them after be_modify() returns? OTOH - I don't know how slapd manages controls nowadays (what decides which controls should be freed, etc) - but I notice ppolicy.c has its very own ctrls_cleanup(). Hopefully that function is general enough that it would be useful to move it into slapd - if it needs its own special control handling, then maybe this issue expands to a need for a general control handling module. ppolicy registers its control as valid with Password Modify, which tells Password Modify it can steal it, etc. One final issue: passwd.c says cb.sc_private = qpw; /* let Modify know this was pwdMod, * if it cares... */ and ppolicy recognizes any Modify with (sc->sc_response == slap_null_cb && sc->sc_private) as the Password Modify operation. Seems no guarantee. I suggest to instead set some specific passwd_<response/cleanup>_sc function which ppolicy can recognize - maybe in addition to the current check, so a 2.4.24-compiled ppolicy can work with 2.4.23 slapd and vice versa.

1 0

(ITS#6775) Client tools often log controls not nicely in LDIF mode
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 LDIF: control: OID <encoded> <known control name>: <human readable> comment: # control: OID <encoded> # <known control name><human readable> A fix is coming. p.

1 0

(ITS#6774) back-meta can send matchedDN with success
by h.b.furuseth＠usit.uio.no 04 Jan '11

04 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.201.41) Submitted by: hallvard With this patch (do not commit:-) Index: servers/slapd/back-meta/search.c @@ -1740,2 +1740,3 @@ rs->sr_ref = ( sres == LDAP_REFERRAL ? rs->sr_v2ref : NULL ); + assert( rs->sr_err || !(rs->sr_text || rs->sr_matched )); send_ldap_result( op, rs ); back-meta oftenfails with just env TESTLOOPS=1 TESTCHILDREN=1 ./run -b hdb test036-meta-concurrency It passes the test if instead of the asser you use rs->sr_matched = ( sres == LDAP_SUCCESS ? NULL : matched ); but I have not looked into whether that cures the symptom or the bug.

1 0

Re: (ITS#6769) Slapd fails to start when olcDbURI attribute is used
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 5:53 PM +0100 Jaap Winius <jwinius(a)umrk.nl> wrote: > Quoting Quanah Gibson-Mount <quanah(a)zimbra.com>: > >> This is a duplicate of ITS#6540, this ITS will be closed. > > Duplicate? That may not be the case. In Pierangelo's own words: > > "That patch was never committed because the reporter of ITS#6540 > said his initial report was not actually relevant for the real > issue he was suffering from... " Your information is out of date. The patch was committed last November. --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#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>: > This is a duplicate of ITS#6540, this ITS will be closed. Duplicate? That may not be the case. In Pierangelo's own words: "That patch was never committed because the reporter of ITS#6540 said his initial report was not actually relevant for the real issue he was suffering from... " Source: http://www.openldap.org/lists/openldap-technical/201011/msg00129.html I filed this report because I'm not sure that the bug for which Pierangelo wrote that patch was ever reported. On the other hand, if the patch has in fact already been committed, then please go ahead and close this ITS. Cheers, Jaap

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Let me confirm that it works as expected with SIMPLE and SASL bind using EXTERNAL (TLS) and DIGEST-MD5. I haven't tried with GSSAPI; the issue might be specific to it. p.

1 0

Re: (ITS#6769) Slapd fails to start when olcDbURI attribute is used
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Monday, January 03, 2011 10:45 PM +0000 jwinius(a)umrk.nl wrote: > The solution is to apply this patch: > > > ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.pa > tch This is a duplicate of ITS#6540, this ITS will be closed. --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#6772) slapcommon.c:495:9: error: SLAPMODIFY undeclared
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 10:19 AM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: RE24 > OS: Linux > URL: > Submission from: (NULL) (84.128.246.210) Don't file bugs on RE24 at this time. This is why you were already asked to leave it alone. --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#6773) Per-connection extra stuff
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> 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. p.

1 0

Re: (ITS#6773) Per-connection extra stuff
by h.b.furuseth＠usit.uio.no 04 Jan '11

04 Jan '11

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? -- Hallvard

1 0

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

04 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando I need to add extra stuff to the Connection structure, to save persistent data across operations. Right now, I'm planning to use it to support RFC 3829 authzid control. <http://www.openldap.org/lists/openldap-devel/201101/msg00005.html> Probably, this can collect other specific stuff like Paged Results c_pagedresults_state, Netscape plugin c_extensions, transactions c_txn_* and more. The patch is straightforward (I'm reproducing it here only for illustrative purposes): -- diff -u -r1.899 slap.h --- servers/slapd/slap.h 31 Dec 2010 19:02:41 -0000 1.899 +++ servers/slapd/slap.h 4 Jan 2011 13:15:07 -0000 @@ -2811,6 +2811,16 @@ /* * represents a connection from an ldap client */ + +/* This is only a header. Actual users should define their own + * structs with the ce_next / ce_key fields at the top and + * whatever else they need following. + */ +typedef struct ConnExtra { + LDAP_SLIST_ENTRY(ConnExtra) ce_next; + void *ce_key; +} ConnExtra; + /* structure state (protected by connections_mutex) */ enum sc_struct_state { SLAP_C_UNINITIALIZED = 0, /* MUST BE ZERO (0) */ @@ -2927,6 +2937,8 @@ void *c_extensions; /* Netscape plugin */ + LDAP_SLIST_HEAD(c_e, ConnExtra) c_extra; /* anything the backend needs */ + /* * Client connection handling */ -- Unless there are objections, I'd commit it. p.

1 0

Re: (ITS#6762) cloak overlay only works on first search entry
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23, HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > The cloak overlay only works on the first entry returned from a search. > Then it removes the callback, and the remaining attributes are > uncloaked. > > I checked this by removing the call to slap_freeself_cb() and the > setting of sc_cleanup, then it worked. And probably got a leak > somewhere, but I don't have time to find the right fix now. Should be fixed in HEAD. Please test. Thanks, p.

1 0

a problem of authentication fail in Ubuntu 10.04,slapd 2.4.21
by cn_gd＠126.com 04 Jan '11

04 Jan '11

hi all, I 'm install slapd follow bellow steps in ubuntu 10.04 lucid strictly: 1. apt-get install slapd * slapd -V @(#) $OpenLDAP: slapd 2.4.21 (Aug 10 2010 17:08:36) $ buildd@yellow:/build/buildd/openldap-2.4.21/debian/build/servers/slapd* 2. dpkg-reconfigure slapd 3.edit /etc/ldap/slapd.d/cn\=config.ldif 4. cat /etc/ldap/slapd.d/cn\=config.ldif dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: "dc=cg,dc=scsio,dc=ac,dc=cn" olcDbDirectory: /home/az/openldap-data olcRootDN: "cn=Manager,dc=cg,dc=scsio,dc=ac,dc=cn" olcRootPW: secret 4. /etc/init.d/slapd restart All step're OK,then I run bellow to test it: 5. ldapsearch -x -D "cn=Manager,dc=cg,dc=scsio,dc=ac,dc=cn" -w "secret" -H ldap://cg.scsio.ac.cn and it show that error: *ldap_bind: Invalid credentials (49) **I try again and again,but it'still the same.( using slappasswd to change it also turn to same problem). I wonder what's go wrong.any help would be greatly appreciated.Thank you in advance! ** *

1 0

(ITS#6772) slapcommon.c:495:9: error: �SLAPMODIFY� undeclared
by michael＠stroeder.com 04 Jan '11

04 Jan '11

Full_Name: Michael Ströder Version: RE24 OS: Linux URL: Submission from: (NULL) (84.128.246.210) Currently there seems to be something missing (did cvs up several times): cc -g -O4 -I../../include -I. -I./slapi -I. -I../../include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -DSLAP_CONFIG_DELETE -c -o slapcommon.o slapcommon.c slapcommon.c: In function slap_tool_init: slapcommon.c:495:9: error: SLAPMODIFY undeclared (first use in this function) slapcommon.c:495:9: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [slapcommon.o] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

1 0

(ITS#6771) Feature request: support for RFC 3829 authzid control
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A simple module that implements RFC 3829 server-side is committed in contrib/slapd-modules/authzid; it only works for single-step bind. Extension to multi-step bind may not be trivial. p.

1 0

(ITS#6770) Proxy authorization fails with SASL-GSSAPI
by jwinius＠umrk.nl 03 Jan '11

03 Jan '11

Full_Name: Jaap Winius Version: 2.4.23-7 OS: Debian squeeze URL: Submission from: (NULL) (2001:888:10:d5f::2) Proxy authorization works with SIMPLE binds, as well as with SASL binds using various other mechanisms, but not with SASL and GSSAPI. In that case it may only work initially, but eventually the problem is that, for no apparent reason, the consumer instead attempts to use a SIMPLE bind to authenticate itself to the provider. Naturally, this fails. For detailed background and debugging info, see this thread: http://www.openldap.org/lists/openldap-technical/201101/msg00002.html

1 0

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

03 Jan '11

Full_Name: Jaap Winius Version: 2.4.23-7 OS: Debian squeeze URL: Submission from: (NULL) (2001:888:10:d5f::2) When attempting configuring slapd as a consumer with proxy authorization, it refuses to start up after the olcDbURI attribute is added to the olcDatabase=ldap entry: ===BEGIN====================== slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! ===END======================== This situation occurs with both the SIMPLE and SASL-GSSAPI bind configurations that I've tested. The solution is to apply this patch: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch For background, see also this thread: http://www.openldap.org/lists/openldap-technical/201011/msg00124.html As you can see, the issue has been known for some time, but I don't know if a bug report has been submitted for it yet, so I thought this would do no harm.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 03 Jan '11

03 Jan '11

--On Thursday, September 30, 2010 11:31 AM +0000 hyc(a)symas.com wrote: Using the latest patch for this issue from HEAD, the issue is no longer present. Using 14 searches (7 full db/7 paged results with a filter), the size of the slapd process is persistent across multiple runs, rather than growing substantially with each iteration of searches. This is using the same system and same database when the problem was originally filed. --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#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 03 Jan '11

03 Jan '11

> back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. > > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. I've patched back-meta in HEAD: if you add the "client-pr" directive, it will perform the client-side of RFC 2696 paged results (either always, with the specified page size, or in response to unsolicited paged results response). This will be totally transparent to the actual client, so the client no longer needs to perform paged results itself. Please test and report. Thanks, p.

1 0

(ITS#6768) NULL OldDN in modrdn operation kill slapd server
by sergeyfd＠gmail.com 03 Jan '11

03 Jan '11

Full_Name: Serge Dubrouski Version: 2.4.23 OS: RedHat ES 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.30.65.103) I ound that ldp.exe tool that comes with Windows is able to successfully kill OpenLDAP 2.4.23 slapd server when one tries to modify DN and submits an empty old DN. No binding is necessary so even anonymous user can easily run a DOS attach against OpenLDAP. Log files in openldap show this: Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 do_modrdn Dec 29 15:19:32 ottawa slapd[11818]: do_modrdn: dn () newrdn (C=US) newsuperior () Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <>, <> Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <C=US> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <c=US>, <c=us> Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 MODRDN dn=""

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by raphael.ouazana＠linagora.com 03 Jan '11

03 Jan '11

Le Sam 1 janvier 2011 19:37, masarati(a)aero.polimi.it a écrit : >> raphael.ouazana(a)linagora.com wrote: >> >>> When using memberOf overlay, a MODRDN request on a member does not >>> update >>> correctly the matching group, even if the memberof-refint option is set >>> to >>> true. >>> >>> In my little understanding, memberof_value_modify calls >>> op->o_bd->be_modify >>> which calls back the overlay code, and finally never reach the backend. >> >> Guess what, modrdn is the only operation test052 does not check :( >> WOrking at it. Thanks, p. > > Fixed in HEAD; please test and report. Please note that test052 and the > corresponding expected output data have been modified to check modrdn. Thank you very much. Tested r1.33->r1.34, and this works fine, great! Regards, Raphaël Ouazana.

1 0

Re: (ITS#6684)
by norbert＠pueschel.net 03 Jan '11

03 Jan '11

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. > 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): 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.

1 0

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

03 Jan '11

On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote: > >(1) Stick more or less with the current behaviour, and change the > >documentation to say that you'll get > > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > >for foreign realms. > > > >However, the odd thing about the current behaviour is that setting > >olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > >the auth DN, regardless of whether it's local or foreign. That's not very > >useful. > > Note that it's not the OpenLDAP code that's sticking this in there; > it's the Cyrus code that's returning this realm in the callback. IMO > our job is to faithfully return what the Cyrus library gave us. The Cyrus library is faithfully passing on the *default* user_realm that you originally passed to sasl_server_new() in servers/slapd/sasl.c (which is global_realm, a.k.a. olcSaslRealm) Then OpenLDAP is sticking it into the authDN, in slap_sasl_getdn() > >I think it would make more sense, if olcSaslRealm is present, to use it to > >*qualify* usernames which don't have a realm. > > That decision is made by the Cyrus library, not us. It does not mandate what you do with the user_realm. You are free to ignore it, use it to qualify usernames which have no realm, or whatever. The documentation for canon_user (in include/sasl.h) says: * If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. The canon_user * facility may treat other characters such as "%" as equivalent to "@". Here is _canonuser_internal from lib/canonusr.c in Cyrus SASL: static int _canonuser_internal(const sasl_utils_t *utils, const char *user, unsigned ulen, unsigned flags __attribute__((unused)), char *out_user, unsigned out_umax, unsigned *out_ulen) ... /* Need to append realm if necessary (see sasl.h) */ if(sconn && sconn->user_realm && !strchr(user, '@')) { u_apprealm = (unsigned) strlen(sconn->user_realm) + 1; } /* Now Copy */ memcpy(out_user, begin_u, MIN(ulen, out_umax)); if(sconn && u_apprealm) { if(ulen >= out_umax) return SASL_BUFOVER; out_user[ulen] = '@'; memcpy(&(out_user[ulen+1]), sconn->user_realm, MIN(u_apprealm-1, out_umax-ulen-1)); } out_user[MIN(ulen + u_apprealm,out_umax)] = '\0'; > >(2) Change the OpenLDAP behaviour so that it matches the documentation at > >http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > > >To do this, the canonicalize function would have to parse the username, > >splitting it on '@' to separate username from realm, so that you would get > > > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > > >If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > >you insert that instead: > > > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > > >And if there's no '@' and no olcSaslRealm, then just leave it alone: > > > > uid=kurt,cn=gssapi,cn=auth > > This has been discussed at great length, read the -devel archives > from 9 or 10 years ago. The fact is that the SASL specification > doesn't reserve '@' as a special character and there is no guarantee > that this is actually a realm separator. There are plenty of > authentication mechanisms where '@' is an integral part of the > username. This suggestion simply won't fly. I suspect that's why canon_user was made pluggable in the first place; if you have your own idea of what constitutes a username with or without a realm then you code for it there. In Cyrus-SASL, plugins/gssapi.c has it hard-coded: if (strchr((char *) name_token.value, (int) '@') != NULL) { ... /* cut off string at '@' */ (strchr(name_without_realm.value,'@'))[0] = '\0'; I agree that non-Kerberos SASL mechanisms might have different username formats; and hence, without additional configuration, OpenLDAP cannot split arbitrary SASL usernames into uid=user,cn=realm. However the current behaviour of olcSaslRealm isn't useful either, since it just gives you uid=user[@realm],cn=olcSaslRealm. I think the most appropriate behaviour for olcSaslRealm would be for it to qualify usernames that don't contain '@' - and if your app doesn't use usernames with '@', then don't set olcSaslRealm. > 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. --- 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

1 0

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

02 Jan '11

Brian Candler wrote: > Now, if my understanding of the user_realm parameter is correct, I think > there are two ways to make OpenLDAP's behaviour consistent with its > documentation. > > (1) Stick more or less with the current behaviour, and change the > documentation to say that you'll get > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > for foreign realms. > > However, the odd thing about the current behaviour is that setting > olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > the auth DN, regardless of whether it's local or foreign. That's not very > useful. Note that it's not the OpenLDAP code that's sticking this in there; it's the Cyrus code that's returning this realm in the callback. IMO our job is to faithfully return what the Cyrus library gave us. > I think it would make more sense, if olcSaslRealm is present, to use it to > *qualify* usernames which don't have a realm. That decision is made by the Cyrus library, not us. > uid=kurt,cn=gssapi,cn=auth > ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth > > i.e. change the canonicalize function to append @user_realm if the username > doesn't contain '@'. > > This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of > stripping off the default realm. > > (2) Change the OpenLDAP behaviour so that it matches the documentation at > http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > To do this, the canonicalize function would have to parse the username, > splitting it on '@' to separate username from realm, so that you would get > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > you insert that instead: > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > And if there's no '@' and no olcSaslRealm, then just leave it alone: > > uid=kurt,cn=gssapi,cn=auth This has been discussed at great length, read the -devel archives from 9 or 10 years ago. The fact is that the SASL specification doesn't reserve '@' as a special character and there is no guarantee that this is actually a realm separator. There are plenty of authentication mechanisms where '@' is an integral part of the username. This suggestion simply won't fly. I don't believe we have any freedom to make any code changes here; feel free to suggest verbiage changes for the documentation. -- -- 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#6766) memberOf does not replicate specially crafted modifications
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando If a modification deletes and recreates a member, something like dn: cn=group changetype: modify delete: member member: cn=user - add: member member: cn=user - the operation succeeds on the provider, but only the delete is replicated. This occurs because the operation, within the memberOf overlay, results in two separate operations: dn: cn=user changetype: modify delete: memberOf memberOf: cn=group dn: cn=user changetype: modify add: memberOf memberOf: cn=group with the same CSN, although corresponding to different operations, so the consumer ignores the second (btw, the CSN is the same of the modification that affects the "cn=group" entry). There may be two solutions: recognize that both operations affect the same entry, and group them, or change the CSN. p.

1 0

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

02 Jan '11

I've been doing some analysis of the Cyrus SASL code. When you say "we're using the parameters as documented by Cyrus", I presume the documentation you refer to is the comments within the source, in which case this all hinges on one line in include/sasl.h: * user_realm -- the user realm (may be NULL in case of client) (in the parameter list for the SASL_CB_CANON_USER callback). So what's meant by "the user realm"? When the callback is actually made (in lib/canonusr.c), the value passed is sconn->user_realm. This appears to be the value you get from sasl_getprop() with SASL_DEFUSERREALM. The user_realm value can be set in sasl_server_new (lib/server.c) and sasl_setprop (lib/common.c). There is a further description of realms in sasl/include.h: * IMPORTANT NOTE: server realms / username syntax * ... A single server may support multiple realms. If the * server knows the realm at connection creation time (e.g., a server * with multiple IP addresses tightly binds one address to a specific * realm) then that realm must be passed in the user_realm field of * the sasl_server_new call. If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. That is: it seems to me fairly clear that the purpose of user_realm is to provide a *default* realm which can be appended to the username when canonicalizing it. As a specific example, the code in _canonuser_internal() appends @<user_realm> if the username doesn't contain '@'. Furthermore, it's also clear from this that the username (SASL_USERNAME) is intended to include '@' and a realm; Cyrus is not designed to split it into a username part and a realm part. This matches what I see when using Cyrus SASL's standalone "sample-server" and "sample-client" programs, with GSSAPI and a client with a kerberos ticket from a different realm to the server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG << sasl_getprop SASL_USERNAME Realm: (NULL) << sasl_getprop SASL_DEFUSERREALM SSF: 56 ... There's a full transcript of this example at http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-December/002177.html Next, looking at plugins/gssapi.c: AFAICS it doesn't make use of user_realm, but does ask GSSAPI if the name without realm is the same as the name with realm, and if so returns the name with the realm stripped off. /* If the id contains a realm get the identifier for the user without the realm and see if it's the same id (i.e. tmartin == tmartin(a)ANDREW.CMU.EDU. If this is the case we just want to return the id (i.e. just "tmartin" */ So, there is code in the GSSAPI plugin to *strip* the realm if it's the same as the default, but I don't think there's code to *separate* the username from the realm if the realm is foreign. Putting all this together: it seems to me that the "user_realm" you see is really just the configured default realm for the session; and that when you query SASL_USERNAME for a Kerberos client, you will see "username" if it's in the default realm, and "username(a)foreign.realm" for other realms. And this matches what I observe when testing this in OpenLDAP. As you suggested, I did bring this up on the cyrus-sasl mailing list (archive URL above), but no replies have been forthcoming so far. Now, if my understanding of the user_realm parameter is correct, I think there are two ways to make OpenLDAP's behaviour consistent with its documentation. (1) Stick more or less with the current behaviour, and change the documentation to say that you'll get uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth for foreign realms. However, the odd thing about the current behaviour is that setting olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into the auth DN, regardless of whether it's local or foreign. That's not very useful. I think it would make more sense, if olcSaslRealm is present, to use it to *qualify* usernames which don't have a realm. uid=kurt,cn=gssapi,cn=auth ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth i.e. change the canonicalize function to append @user_realm if the username doesn't contain '@'. This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of stripping off the default realm. (2) Change the OpenLDAP behaviour so that it matches the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI To do this, the canonicalize function would have to parse the username, splitting it on '@' to separate username from realm, so that you would get uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth If the username doesn't contain '@', but olcSaslRealm is set, then I suggest you insert that instead: uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth And if there's no '@' and no olcSaslRealm, then just leave it alone: uid=kurt,cn=gssapi,cn=auth Regards, Brian.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

>> If yes, do I need to produce other infos related to my environment? > > Hi, I have fixed a couple of bugs in reqControls validation. However a > problem remains: the validator expects control values to consist in > hexadecimal digits (0-9, a-f), while your values in some cases aren't. > This could be related to interoperation issues between different slapd > versions, although I couldn't go back to the point where this change in > syntax occurred, if any. Spotted (and fixed) the bug in the enconding part of control values. It shouldnow be fixed. Please test and report. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Marco Pizzoli > Version: 2.4.23 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > I had a problem with my Accesslog database. > I was investigating an anomaly that I had and, in doing this, I tried to: > - backup (slapcat) my accesslog db > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > - slapadd the db > > In slapadd I obtained this error: > > --- BEGIN > /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l > /srv/bck/dump_db_log.ldif.20100916 > . 0.00% eta 08h35m elapsed spd 90.2 > k/s > str2entry: invalid value for attributeType reqControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=4907) > - 0.01% eta 05h58m elapsed spd 205.7 > k/s > Closing DB... > --- END > > I went to that line and found this entry: > > --- BEGIN > dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 > 330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913065628Z > --- END > > Having produced this ldif using slapcat and not having "touched" the > environment > in between could I assume this to be a bug? > The entry showed is related to an access made by another OL server of my > deployment, which is in mirrormode(=true). > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 > > > I deleted this entry and retried the import. > Now I have the following error: > --- BEGIN > /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l > /tmp/dump_db_log.ldif.20100916_Corrected > " 4.69% eta 01h07m elapsed 03m19s spd 542.3 > k/s > str2entry: invalid value for attributeType reqRespControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3099715) > * 4.70% eta 01h07m elapsed 03m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it > objectClass: auditBind > structuralObjectClass: auditBind > reqStart: 20100913093021.000000Z > reqEnd: 20100913093021.000001Z > reqType: bind > reqSession: 2746 > reqAuthzID: > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} > reqDN: uid=pe1597,ou=People,dc=mycorp.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913093021Z > --- END > > Is this a software bug? > > If yes, do I need to produce other infos related to my environment? Hi, I have fixed a couple of bugs in reqControls validation. However a problem remains: the validator expects control values to consist in hexadecimal digits (0-9, a-f), while your values in some cases aren't. This could be related to interoperation issues between different slapd versions, although I couldn't go back to the point where this change in syntax occurred, if any. p.

1 0

Re: (ITS#6749) Shut up "configure monitor database to enable"
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Please don't give the "configure monitor database to enable" message > by default. > > Either just remove it, or better, stop cn=config from adding a default > olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value > can still default to True if the attribute is absent.) Then you can > give the message if the _admin_ has explicitly asked for monitoring, > instead of if slapd has asked for it. I disagree; it is not cn=config that defaults database monitoring to TRUE; actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as soon as back-monitor support is compiled and the specific backend monitoring is successfully initilized. Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of LDAP_DEBUG_ANY. I understand that one could presume that the lack of database monitor in the configuration indicates that monitoring is not desired; this warning, however, tries to address a typical configuration error, when admins just forget to configure it. p.

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

> raphael.ouazana(a)linagora.com wrote: > >> When using memberOf overlay, a MODRDN request on a member does not >> update >> correctly the matching group, even if the memberof-refint option is set >> to >> true. >> >> In my little understanding, memberof_value_modify calls >> op->o_bd->be_modify >> which calls back the overlay code, and finally never reach the backend. > > Guess what, modrdn is the only operation test052 does not check :( > WOrking at it. Thanks, p. Fixed in HEAD; please test and report. Please note that test052 and the corresponding expected output data have been modified to check modrdn. p.

1 0

(ITS#6765) Server-side support of "Verify Credentials" extop
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando Added module in contrib/slapd-modules/vc/; no spec yet, simply mimicking the companion of what is currently implemented in libraries/libldap/vc.c. The current code should support SASL; untested yet, since the client does not implement SASL support yet. p.

1 0

(ITS#6764) ber_flatten() should return -1 on unmatched "{" "}"
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando also per <draft-ietf-ldapext-ldap-c-api>. p.

1 0

Re: (ITS#6758) Cleaning up SlapReply usage
by hyc＠symas.com 31 Dec '10

31 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Mostly done with the easily spotted cases. Hopefully HEAD's code > stayed valid through my commits. Need to think some more for the > rest. The decisions with greater chance of breaking things > remain, like ITS#6763. > > Other issues: > > * hyc, please have a look at slapd/bconfig.c 1.419. If I have > gotten things wrong, that one summarizes my mistakes nicely:-) 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) -- -- 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 31 Dec '10

31 Dec '10

Mostly done with the easily spotted cases. Hopefully HEAD's code stayed valid through my commits. Need to think some more for the rest. The decisions with greater chance of breaking things remain, like ITS#6763. Other issues: * hyc, please have a look at slapd/bconfig.c 1.419. If I have gotten things wrong, that one summarizes my mistakes nicely:-) * If slap_send_ldap_result() or send_ldap_disconnect() see an entry with REP_ENTRY_MUST<RELEASE/BEFREED> and REP_SEARCH/SEARCHREF, should release/free the entry? That helps code which sends error without freeing sr_entry. It breaks if the entry comes from another Operation, or if the caller reuses a Search SlapReply for a non-Search and trusts rs->sr_un.sru_search to stay untouched. * Is the code getting clean enough that slap_send_search_entry's cleanup code can flush the entry independently of whether op->o_tag == LDAP_REQ_SEARCH? * slapi/slapi_pblock.c 1.81: /* TODO: Should REP_ENTRY_MODIFIABLE be set? */ I've no idea, and I've more pressing things to look at... Notes on the updates: * "Reset some SlapReply flags & data" commits vs "avoid SlapReply reuse" commits: The combination might be redundant/overcautious, but tries to catch problems from remaining unclean code from both ends. * result.c, freeing as well as releasing entries as soon as possible: More readable, and since the entry isn't needed: The sooner we get rid of it, the less chance for an entry leak. * commits "Use rs_*() to manage SlapReply entries." Switching to rs_flush_entry(): - result.c:slap_send_search_entry(), overlays/pcache.c, overlays/translucent.c, slapi/slapi_pblock.c: These did not clear the MODIFIABLE flag along with MUSTBEFREED. Switching to use rs_ensure_entry_modifiable(): - syncprov_operational(), overlay collect: noop change (except operational should not update the entry) - overlay valsort: It needlessly required REP_ENTRY_MUSTBEFREED as well as MODIFIABLE. But the entry can also be MODIFIABLE and e.g. on the stack. - contrib overlays cloak, usn: Had entry leaks. -- Hallvard

1 0

(ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slap_send_search_entry() does not always free/release the entry and call slap_cleanup_play() on error. slap_send_search_reference() calls slap_cleanup_play(), but does not always free/release the entry. I expect both functions always should do both, but don't know enough myself to be sure. Resolution needed for ITS#6758 (SlapReply) - who should be responsible for clearing out the entry?

1 0

(ITS#6762) cloak overlay only works on first search entry
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The cloak overlay only works on the first entry returned from a search. Then it removes the callback, and the remaining attributes are uncloaked. I checked this by removing the call to slap_freeself_cb() and the setting of sc_cleanup, then it worked. And probably got a leak somewhere, but I don't have time to find the right fix now.

1 0

(ITS#6761) contrib usn overlay broken
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The usn overlay: - Has init function usn_init instead of usn_initialize. - Won't start, the attributes need a SYNTAX slapd knows and USAGE directoryOperation after NO-USER-MODIFICATION. - Modifies sr->sr_entry in usn_operational() instead of putting the attribute in rs->sr_operational_attrs. See back-bdb/operational.c for an example. Note, backend.c says /* NOTE: backend_operational() is also called * when returning results, so it's supposed * to do no harm to entries */ which presumably means something more than just having to dup the entry and set MUSTBEFREED, since otherwise that comment applies to much more than just backend_operational(). In fact, usn_operational() has some misindented code if ( !a ) { for ( ap = &rs->sr_operational_attrs; *ap; ap=&(*ap)->a_next ); a = attr_alloc( ad_usnChanged ); *ap = a; } which looks like it does something closer to that. - When I tried to slapadd some entires (using Octet String syntax) only the first entry got an USN. Oh well, this wasn't what I was supposed to be doing today. I'm just patching the overlay blindly for some other things (ITS#6758).

1 0

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

31 Dec '10

I get similar behaviour using Cyrus SASL's sample-client and sample-server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG Realm: (NULL) SSF: 56 ... Now, in sample-server.c, the displayed realm comes from result = sasl_getprop(conn, SASL_DEFUSERREALM, (const void **)&data); which suggests this is intended to be the default realm, not the realm of the user connecting. And clearly the username does include the Kerberos realm. But I'm having difficulty finding the corresponding OpenLDAP code to extract the realm. Is it making use of session callbacks, and expects Cyrus to call slap_sasl_canonicalize (SASL_CB_CANON_USER) with the user_realm parameter? Regards, Brian.

1 0

(ITS#6760) rwm broken entry handling
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rwm_entry_get_rw() returns failure with an entry in *ep if rwm_send_entry() fails. rwm_send_entry() does not honor REP_ENTRY_MUSTBEFREED. And its ITS#6423 bugcatch can be done before entry_dup(). Fixing - I think - but my fix could use some extra eyes. In particuar, am I right about using be_entry_release_r() or should it have used overlay_entry_release_ov() which rs_replace_entry() uses? Or should rwm_send_entry() use different release methods depending on whether it is called by rwm.on_response or rwm.on_bi.bi_entry_get_rw?

1 0

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

30 Dec '10

b.candler(a)pobox.com wrote: > Full_Name: Brian Candler > Version: 2.4.21 > OS: Ubuntu 10.04.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.114.104.19) > > > DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two > example authorization DNs built from SASL/GSSAPI: > > "a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated > DN: > uid=kurt,cn=example.com,cn=gssapi,cn=auth > and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN: > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth" > > Experimentation shows that the actual behaviour is different. > > You could treat this either as a behaviour error or a documentation error - if > the latter, the olcSaslRealm is pretty useless, because if set it appears in all > auth DNs (for both local and foreign realms) Could be a bug, but we're using the parameters as documented by Cyrus. I suggest you file this bug report with them instead. -- -- 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#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 30 Dec '10

30 Dec '10

jgilmour(a)techsmog.com wrote: > Full_Name: Josh Gilmour > Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) > OS: CentOS release 5.4 32bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.112.23.58) > > > I get a segfault when using the following command and applying a filter file. If > we remove the -f, the command runs properly. It doesn't seem to be a major > security issue (or one at all, I'm not sure), but it does seem to be a bug I > believe... OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a current release please followup with the relevant stack trace, otherwise this ITS will be closed. Currently I see no such symptom in 2.4.x. -- -- 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#6678
by hyc＠symas.com 30 Dec '10

30 Dec '10

The best thing to do in a hang situation is to attach to the server with gdb and get a stack trace of all of the active threads. http://www.openldap.org/faq/data/cache/59.html -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs