- openldap-bugs - openldap.org

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 19 Jul '17

19 Jul '17

On Tue, Jul 18, 2017 at 05:27:40PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > Using the behaviour above, I have been able to trigger a desync, the > script and testrun directory from it happening are available here: > ftp://ftp.openldap.org/incoming/its8444-desync.tgz It's super easy to reproduce the desync when upping MMR to 6 in that script even without memberof (no process re-nicing necessary actually). --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8694) Windows builds fail to install event information
by quanah＠symas.com 18 Jul '17

18 Jul '17

--On Tuesday, July 18, 2017 5:15 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Running "slapd.exe install" is supposed to add the event information in > windows for startup/shutdown (1280/1281). However, this broke at some > point, and no longer provides that information. This causes the event > viewer in Windows to complain that the installation may be corrupt. Windows 10 and Windows 2012 both show this behavior. I don't have anything older than that to test against yet. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 18 Jul '17

18 Jul '17

On Thu, Jun 08, 2017 at 06:36:02PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > A more self-contained log of the same issue, available at > ftp://ftp.openldap.org/incoming/its8444.log >=20 > (line numbers below are against current master, commit > 91f4d3a6b75e73bf4ea498e83e2e4cb4e7a320e0) >=20 > There are some things that occur in all the failures I have seen so far= : > - the server that received the operation (#1) sends the accesslog entry > with no CSN in the cookie, then another provider (#2) picks up this > message and relays it to its consumers, this one with a CSN in the > cookie > - a consumer picks up these two in short succession, in the log above, > processing of the one from #2 is finished first (they are being > processed concurrently) >=20 > Usually, once one of them gets processed, the new CSN should be noted > and the other threads should just skip it (syncrepl.c:943 and onwards). > In this one, having no CSN in the cookie seems to allow both to process > so far as to run syncrepl_message_to_op(), and one of them will then > inevitably fail to add the entry. >=20 > I don't understand yet why server #1 sends the operations without a CSN > in the cookie and (especially if I reorder the overlays to set up > memberof last), the race goes the other way around and the operation to > fail is the one from server #2. >=20 > My take on it was that in a delta-sync environment all entries would be > passed with a new CSN and that should end up in the cookie, allowing > syncrepl.c:986 to do its job. Using the behaviour above, I have been able to trigger a desync, the script and testrun directory from it happening are available here: ftp://ftp.openldap.org/incoming/its8444-desync.tgz In srv3, looking at cn=3Daccesslog, we can see that the increment by 2 ha= s been applied (and logged) twice with the same entryCSN, as: reqStart=3D20170718155142.000007Z,cn=3Daccesslog reqStart=3D20170718155142.000009Z,cn=3Daccesslog also seen in the log around those two DNs above. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8694) Windows builds fail to install event information
by quanah＠openldap.org 18 Jul '17

18 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Running "slapd.exe install" is supposed to add the event information in windows for startup/shutdown (1280/1281). However, this broke at some point, and no longer provides that information. This causes the event viewer in Windows to complain that the installation may be corrupt.

1 0

Re: (ITS#8472) slapd killed after ldapadd
by hyc＠symas.com 14 Jul '17

14 Jul '17

ondra(a)mistotebe.net wrote: > On Fri, Jul 14, 2017 at 09:02:18AM +0000, russell(a)samknows.com wrote: >> 59687dbf ch_calloc of 1 elems of 0 bytes failed >> slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion >> `0' failed. >> Aborted > > If no indexes remain, mdb_attr_dbs_open calls ch_calloc(1, 0), but > ch_malloc/ch_calloc do not expect that. > > I'd fix ch_calloc/ch_malloc, but depends whether that's the right thing > to do, is it intentional to assert when a zero size is requested? Yes. > ber_memalloc has an assert there if LDAP_MEMORY_DEBUG has the second bit > set. Hallvard, Howard? > > If it's fine to change the ch_ functions, then a patch is available at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170714-ITS-8472.patch No. In this case, back-mdb never expects the number of indexed attributes to be zero. (At the least, objectclass must always have an equality index.) back-mdb can be patched to avoid this particular crash. But as a rule, you're expected to make all changes to the index config in a single Modify op. Not delete all the indices in one operation, and then define new indices in a new operation. -- -- 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#8472) slapd killed after ldapadd
by ondra＠mistotebe.net 14 Jul '17

14 Jul '17

On Fri, Jul 14, 2017 at 09:02:18AM +0000, russell(a)samknows.com wrote: > 59687dbf ch_calloc of 1 elems of 0 bytes failed > slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion > `0' failed. > Aborted If no indexes remain, mdb_attr_dbs_open calls ch_calloc(1, 0), but ch_malloc/ch_calloc do not expect that. I'd fix ch_calloc/ch_malloc, but depends whether that's the right thing to do, is it intentional to assert when a zero size is requested? ber_memalloc has an assert there if LDAP_MEMORY_DEBUG has the second bit set. Hallvard, Howard? If it's fine to change the ch_ functions, then a patch is available at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170714-ITS-8472.patch -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8472) slapd killed after ldapadd
by russell＠samknows.com 14 Jul '17

14 Jul '17

--001a113c349ed7ce5c0554434d63 Content-Type: text/plain; charset="UTF-8" Hi Support It appears I have just manage to hit the exact same issue as Dominik here. I have attached a back-trace for this issue to this email: gdb.txt (though I'm not sure how ITS will handle an attachment - will repost if necessary). --------------------------------------------- Command as it was used/run: --------------------------------------------- ldapmodify -Z -D cn=admin,dc=sk,dc=lan -w[redacted] -H ldapi:/// dn: olcDatabase={1}mdb,cn=config delete: olcDbIndex modifying entry "olcDatabase={1}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) ---------------------------------------------------------------------------------------------- Debug function call trace from the exact moment LDAP aborted: ---------------------------------------------------------------------------------------------- 59687dbf connection_get(22): got connid=1002 59687dbf connection_read(22): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 58 contents: 59687dbf op tag 0x66, time 1500020159 ber_get_next 59687dbf conn=1002 op=2 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 59687dbf >>> dnPrettyNormal: <olcDatabase={1}mdb,cn=config> 59687dbf <<< dnPrettyNormal: <olcDatabase={1}mdb,cn=config>, <olcDatabase={1}mdb,cn=config> 59687dbf >>> dnNormalize: <cn=sysadmin,ou=groups,dc=sk,dc=lan> 59687dbf <<< dnNormalize: <cn=sysadmin,ou=groups,dc=sk,dc=lan> 59687dbf mdb_dn2entry("cn=sysadmin,ou=groups,dc=sk,dc=lan") 59687dbf => mdb_dn2id("cn=sysadmin,ou=groups,dc=sk,dc=lan") 59687dbf <= mdb_dn2id: got id=0xf 59687dbf => mdb_entry_decode: 59687dbf <= mdb_entry_decode 59687dbf mdb_entry_get: rc=0 59687dbf >>> dnNormalize: <cn=sys-replication,ou=system,dc=sk,dc=lan> 59687dbf <<< dnNormalize: <cn=sys-replication,ou=system,dc=sk,dc=lan> 59687dbf mdb_dn2entry("cn=sys-replication,ou=system,dc=sk,dc=lan") 59687dbf => mdb_dn2id("cn=sys-replication,ou=system,dc=sk,dc=lan") 59687dbf <= mdb_dn2id: got id=0x9 59687dbf => mdb_entry_decode: 59687dbf <= mdb_entry_decode 59687dbf mdb_entry_get: rc=16 59687dbf syncprov_matchops: sid 002 fscope 1 rc 6 59687dbf oc_check_required entry (olcDatabase={1}mdb,cn=config), objectClass "olcMdbConfig" 59687dbf oc_check_allowed type "objectClass" 59687dbf oc_check_allowed type "olcDatabase" 59687dbf oc_check_allowed type "olcDbDirectory" 59687dbf oc_check_allowed type "olcSuffix" 59687dbf oc_check_allowed type "olcAccess" 59687dbf oc_check_allowed type "olcLastMod" 59687dbf oc_check_allowed type "olcLimits" 59687dbf oc_check_allowed type "olcRootDN" 59687dbf oc_check_allowed type "olcRootPW" 59687dbf oc_check_allowed type "olcSyncrepl" 59687dbf oc_check_allowed type "olcMirrorMode" 59687dbf oc_check_allowed type "olcDbCheckpoint" 59687dbf oc_check_allowed type "olcDbMaxSize" 59687dbf oc_check_allowed type "structuralObjectClass" 59687dbf oc_check_allowed type "entryUUID" 59687dbf oc_check_allowed type "creatorsName" 59687dbf oc_check_allowed type "createTimestamp" 59687dbf oc_check_allowed type "entryCSN" 59687dbf oc_check_allowed type "modifiersName" 59687dbf oc_check_allowed type "modifyTimestamp" 59687dbf ch_calloc of 1 elems of 0 bytes failed slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion `0' failed. Aborted ---------------------- Exact Version: ---------------------- @(#) $OpenLDAP: slapd (Ubuntu) (May 30 2017 19:20:53) $ buildd@lgw01-18:/build/openldap-JXEADB/openldap-2.4.42+dfsg/debian/build/servers/slapd Hope this all helps to diagnose the issue and get a fix out for it. I appreciate that the version I have is not the latest, but I have seen nothing in the Changelogs of the latest versions to suggest that a newer version could actually fix this, and besides, Dominik experienced the issue in a newer release already (2.4.44) Full_name: Russell Knighton Version: 2.4.42 OS: Ubuntu 16.04 -- Russell Knighton (Systems Administrator) SamKnows Ltd, 135 Park St., London, SE1 9EA --001a113c349ed7ce5c0554434d63 Content-Type: text/plain; charset="UTF-8"; name="gdb.txt" Content-Disposition: attachment; filename="gdb.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j53mlqcx0 IzAgIDB4MDAwMDdmZmZmNjcyZTQyOCBpbiBfX0dJX3JhaXNlIChzaWc9c2lnQGVudHJ5PTYpIGF0 IC4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3JhaXNlLmM6NTQKICAgICAgICByZXN1bHR2YXIg PSAwCiAgICAgICAgcGlkID0gMTEzMTcKICAgICAgICBzZWxmdGlkID0gMTEzMjQKIzEgIDB4MDAw MDdmZmZmNjczMDAyYSBpbiBfX0dJX2Fib3J0ICgpIGF0IGFib3J0LmM6ODkKICAgICAgICBzYXZl X3N0YWdlID0gMgogICAgICAgIGFjdCA9IHtfX3NpZ2FjdGlvbl9oYW5kbGVyID0ge3NhX2hhbmRs ZXIgPSAweDQsIHNhX3NpZ2FjdGlvbiA9IDB4NH0sIHNhX21hc2sgPSB7X192YWwgPSB7MCwgOTM4 MjQ5OTY0NjY5NDQsIDE0MDczNjA5NjE0OTM5MiwgNDcyNDQ2NDAyNTYsIDE0MDczNzM1NDA4NDM1 MiwgOTM4MjQ5OTMxNzEyODYsIDEwNywgOTM4MjQ5OTMxMDAyOTYsIDE0MDczNzM1MjE1OTI0OCwg MCwgMTQwNzM3MzI4NDM2NTQwLCAKICAgICAgICAgICAgICAxNDA3MzczMjk1MzM0NTYsIDE0MDcz NzMyOTU0NzEwNCwgMCwgMTQwNzM3MzI5NTMzNDU2LCA5MzgyNDk5MzE3MTI4Nn19LCBzYV9mbGFn cyA9IC0xMzQyNzA5NzYsIHNhX3Jlc3RvcmVyID0gMHg1NTU1NTU2Mzk3NTZ9CiAgICAgICAgc2ln cyA9IHtfX3ZhbCA9IHszMiwgMCA8cmVwZWF0cyAxNSB0aW1lcz59fQojMiAgMHgwMDAwN2ZmZmY2 NzI2YmQ3IGluIF9fYXNzZXJ0X2ZhaWxfYmFzZSAoZm10PTxvcHRpbWl6ZWQgb3V0PiwgYXNzZXJ0 aW9uPWFzc2VydGlvbkBlbnRyeT0weDU1NTU1NTYzOTc1NiAiMCIsIGZpbGU9ZmlsZUBlbnRyeT0w eDU1NTU1NTYyODE2OCAiLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jaF9tYWxsb2MuYyIsIGxp bmU9bGluZUBlbnRyeT0xMDcsIAogICAgZnVuY3Rpb249ZnVuY3Rpb25AZW50cnk9MHg1NTU1NTU2 MjgyMDggPF9fUFJFVFRZX0ZVTkNUSU9OX18uMTM0MTM+ICJjaF9jYWxsb2MiKSBhdCBhc3NlcnQu Yzo5MgogICAgICAgIHN0ciA9IDB4N2ZmZmEwMTNkNjkwICIiCiAgICAgICAgdG90YWwgPSA0MDk2 CiMzICAweDAwMDA3ZmZmZjY3MjZjODIgaW4gX19HSV9fX2Fzc2VydF9mYWlsIChhc3NlcnRpb249 YXNzZXJ0aW9uQGVudHJ5PTB4NTU1NTU1NjM5NzU2ICIwIiwgZmlsZT1maWxlQGVudHJ5PTB4NTU1 NTU1NjI4MTY4ICIuLi8uLi8uLi8uLi9zZXJ2ZXJzL3NsYXBkL2NoX21hbGxvYy5jIiwgbGluZT1s aW5lQGVudHJ5PTEwNywgCiAgICBmdW5jdGlvbj1mdW5jdGlvbkBlbnRyeT0weDU1NTU1NTYyODIw OCA8X19QUkVUVFlfRlVOQ1RJT05fXy4xMzQxMz4gImNoX2NhbGxvYyIpIGF0IGFzc2VydC5jOjEw MQpObyBsb2NhbHMuCiM0ICAweDAwMDA1NTU1NTU1YTliMTEgaW4gY2hfY2FsbG9jIChuZWxlbT1u ZWxlbUBlbnRyeT0xLCBzaXplPTApIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvY2hfbWFs bG9jLmM6MTA3CiAgICAgICAgc2l6ZSA9IDAKICAgICAgICBuZWxlbSA9IDEKICAgICAgICBuZXcg PSA8b3B0aW1pemVkIG91dD4KIzUgIDB4MDAwMDdmZmZlZjRjODliMyBpbiBtZGJfYXR0cl9kYnNf b3BlbiAoYmU9MHg1NTU1NTU5ZDdjYTAsIHR4MD10eDBAZW50cnk9MHgwLCBjcj1jckBlbnRyeT0w eDdmZmZhZDA0YjNjMCkgYXQgLi4vLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iYWNrLW1kYi9h dHRyLmM6MTEzCiAgICAgICAgbWRiID0gMHg3ZmZmZjdlMWQwMTAKICAgICAgICB0eG4gPSAweDU1 NTU1NWJkMTY5MAogICAgICAgIGRiaXMgPSAweDAKICAgICAgICBpID0gPG9wdGltaXplZCBvdXQ+ CiAgICAgICAgZmxhZ3MgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICByYyA9IDAKIzYgIDB4MDAw MDdmZmZlZjRiY2FhNSBpbiBtZGJfY2ZfY2xlYW51cCAoYz0weDdmZmZhZDA0YTM3MCkgYXQgLi4v Li4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iYWNrLW1kYi9jb25maWcuYzoyNTgKICAgICAgICBt ZGIgPSAweDdmZmZmN2UxZDAxMAogICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiM3ICAweDAw MDA1NTU1NTU1Nzc3MDYgaW4gY29uZmlnX21vZGlmeV9pbnRlcm5hbCAoY2E9MHg3ZmZmYWQwNGEz NzAsIHJzPTxvcHRpbWl6ZWQgb3V0Piwgb3A9PG9wdGltaXplZCBvdXQ+LCBjZT08b3B0aW1pemVk IG91dD4pIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvYmNvbmZpZy5jOjU4MTYKICAgICAg ICBlID0gMHg1NTU1NTU5NGE2ZjgKICAgICAgICBzYXZlX2F0dHJzID0gMHg1NTU1NTU5NjA0NTAK ICAgICAgICBhID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgY29sc3QgPSAweDdmZmZhMDEzMGUx MAogICAgICAgIGkgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBkZWxzID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgcmMgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvY19hdCA9IDxvcHRpbWl6 ZWQgb3V0PgogICAgICAgIG5vY3MgPSAzCiAgICAgICAgcHRyID0gPG9wdGltaXplZCBvdXQ+CiAg ICAgICAgcyA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGRlbHRhaWwgPSAweDAKICAgICAgICBt bCA9IDB4MAojOCAgY29uZmlnX2JhY2tfbW9kaWZ5IChvcD08b3B0aW1pemVkIG91dD4sIHJzPTxv cHRpbWl6ZWQgb3V0PikgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iY29uZmlnLmM6NTkw NgogICAgICAgIGNmYiA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGNlID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgbGFzdCA9IDB4NTU1NTU1OTVkYTkwCiAgICAgICAgbWwgPSA8b3B0aW1pemVk IG91dD4KICAgICAgICBjYSA9IHthcmdjID0gMSwgYXJndiA9IDB4N2ZmZmEwMTNkODYwLCBhcmd2 X3NpemUgPSA1MTMsIGxpbmUgPSAweDAsIHRsaW5lID0gMHgwLCBmbmFtZSA9IDB4NTU1NTU1NjFj OGUxICJzbGFwZCIsIGxpbmVubyA9IDAsIGxvZyA9ICJiYWNrLWNvbmZpZyIsICdcMDAwJyA8cmVw ZWF0cyA0MTEyIHRpbWVzPiwgcmVwbHkgPSB7ZXJyID0gMCwgbXNnID0gJ1wwMDAnIDxyZXBlYXRz IDI1NSB0aW1lcz59LCAKICAgICAgICAgIGRlcHRoID0gMCwgdmFseCA9IC0xLCB2YWx1ZXMgPSB7 dl9pbnQgPSAwLCB2X3VpbnQgPSAwLCB2X2xvbmcgPSAwLCB2X3Vsb25nID0gMCwgdl9iZXJfdCA9 IDAsIHZfc3RyaW5nID0gMHgwLCB2X2J2ID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHZf ZG4gPSB7dmRuX2RuID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHZkbl9uZG4gPSB7YnZf bGVuID0gMCwgYnZfdmFsID0gMHgwfX0sIAogICAgICAgICAgICB2X2FkID0gMHgwfSwgcnZhbHVl X3ZhbHMgPSAweDAsIHJ2YWx1ZV9udmFscyA9IDB4MCwgb3AgPSAxLCB0eXBlID0gNSwgY2Ffb3Ag PSAweDdmZmZhMDEyZDQwMCwgYmUgPSAweDU1NTU1NTlkN2NhMCwgYmkgPSAweDAsIGNhX2VudHJ5 ID0gMHg1NTU1NTU5NGE2ZjgsIGNhX3ByaXZhdGUgPSAweDAsIGNsZWFudXAgPSAweDdmZmZlZjRi Y2E2MCA8bWRiX2NmX2NsZWFudXA+LCAKICAgICAgICAgIHRhYmxlID0gQ2Z0X0RhdGFiYXNlfQog ICAgICAgIHJkbiA9IHtidl9sZW4gPSAxMSwgYnZfdmFsID0gMHg1NTU1NTU5ZGJlYjAgIm9sY0Rh dGFiYXNlPXsxfW1kYixjbj1jb25maWcifQogICAgICAgIHB0ciA9IDxvcHRpbWl6ZWQgb3V0Pgog ICAgICAgIHJhZCA9IDB4NTU1NTU1OTJlMzAwCiAgICAgICAgZG9fcGF1c2UgPSA8b3B0aW1pemVk IG91dD4KIzkgIDB4MDAwMDU1NTU1NTVmYjIwMiBpbiBvdmVybGF5X29wX3dhbGsgKG9wPW9wQGVu dHJ5PTB4N2ZmZmEwMTJkNDAwLCBycz0weDdmZmZhZDA0Yzk4MCwgd2hpY2g9b3BfbW9kaWZ5LCBv aT0weDU1NTU1NTlkNDdkMCwgb249PG9wdGltaXplZCBvdXQ+KSBhdCAuLi8uLi8uLi8uLi9zZXJ2 ZXJzL3NsYXBkL2JhY2tvdmVyLmM6Njc3CiAgICAgICAgZnVuYyA9IDxvcHRpbWl6ZWQgb3V0Pgog ICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiMxMCAweDAwMDA1NTU1NTU1ZmIzNWQgaW4gb3Zl cl9vcF9mdW5jIChvcD0weDdmZmZhMDEyZDQwMCwgcnM9PG9wdGltaXplZCBvdXQ+LCB3aGljaD08 b3B0aW1pemVkIG91dD4pIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvYmFja292ZXIuYzo3 MzAKICAgICAgICBvaSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIG9uID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgYmUgPSAweDU1NTU1NTk0OTkzMAogICAgICAgIGRiID0ge2JkX2luZm8gPSAw eDU1NTU1NTg4M2Y0MCA8c2xhcF9iaW5mbz4sIGJkX3NlbGYgPSAweDU1NTU1NTk0OTkzMCwgYmVf Y3RybHMgPSAnXDAwMCcgPHJlcGVhdHMgMTQgdGltZXM+LCAiXDAwMVwwMDBcMDAwXDAwMFwwMDEi LCAnXDAwMCcgPHJlcGVhdHMgMTMgdGltZXM+LCAiXDAwMSIsIGJlX2ZsYWdzID0gNjkyNDgwLCBi ZV9yZXN0cmljdG9wcyA9IDAsIGJlX3JlcXVpcmVzID0gMCwgCiAgICAgICAgICBiZV9zc2Zfc2V0 ID0ge3Nzc19zc2YgPSAwLCBzc3NfdHJhbnNwb3J0ID0gMCwgc3NzX3RscyA9IDAsIHNzc19zYXNs ID0gMCwgc3NzX3VwZGF0ZV9zc2YgPSAwLCBzc3NfdXBkYXRlX3RyYW5zcG9ydCA9IDAsIHNzc191 cGRhdGVfdGxzID0gMCwgc3NzX3VwZGF0ZV9zYXNsID0gMCwgc3NzX3NpbXBsZV9iaW5kID0gMH0s IGJlX3N1ZmZpeCA9IDB4NTU1NTU1OTQ5YjMwLCAKICAgICAgICAgIGJlX25zdWZmaXggPSAweDU1 NTU1NTk0OWI4MCwgYmVfc2NoZW1hZG4gPSB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgYmVf c2NoZW1hbmRuID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIGJlX3Jvb3RkbiA9IHtidl9s ZW4gPSAyNywgYnZfdmFsID0gMHg1NTU1NTU5ZDM5ZjAgImNuPWFkbWluLGRjPXNhbWtub3dzLGRj PWNvbSJ9LCBiZV9yb290bmRuID0ge2J2X2xlbiA9IDI3LCAKICAgICAgICAgICAgYnZfdmFsID0g MHg1NTU1NTU5Y2MzYzAgImNuPWFkbWluLGRjPXNhbWtub3dzLGRjPWNvbSJ9LCBiZV9yb290cHcg PSB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgYmVfbWF4X2RlcmVmX2RlcHRoID0gMTUsIGJl X2RlZl9saW1pdCA9IHtsbXNfdF9zb2Z0ID0gMzYwMCwgbG1zX3RfaGFyZCA9IDAsIGxtc19zX3Nv ZnQgPSA1MDAsIGxtc19zX2hhcmQgPSAwLCAKICAgICAgICAgICAgbG1zX3NfdW5jaGVja2VkID0g LTEsIGxtc19zX3ByID0gMCwgbG1zX3NfcHJfaGlkZSA9IDAsIGxtc19zX3ByX3RvdGFsID0gMH0s IGJlX2xpbWl0cyA9IDB4MCwgYmVfYWNsID0gMHg1NTU1NTU5ZDJlYzAsIGJlX2RmbHRhY2Nlc3Mg PSBBQ0xfTk9ORSwgYmVfZXh0cmFfYW5saXN0ID0gMHgwLCBiZV91cGRhdGVfbmRuID0ge2J2X2xl biA9IDAsIGJ2X3ZhbCA9IDB4MH0sIAogICAgICAgICAgYmVfdXBkYXRlX3JlZnMgPSAweDAsIGJl X3BlbmRpbmdfY3NuX2xpc3QgPSAweDU1NTU1NThmOGNiMCwgYmVfcGNsX211dGV4ID0ge19fZGF0 YSA9IHtfX2xvY2sgPSAwLCBfX2NvdW50ID0gMCwgX19vd25lciA9IDAsIF9fbnVzZXJzID0gMCwg X19raW5kID0gMCwgX19zcGlucyA9IDAsIF9fZWxpc2lvbiA9IDAsIF9fbGlzdCA9IHtfX3ByZXYg PSAweDAsIF9fbmV4dCA9IDB4MH19LCAKICAgICAgICAgICAgX19zaXplID0gJ1wwMDAnIDxyZXBl YXRzIDM5IHRpbWVzPiwgX19hbGlnbiA9IDB9LCBiZV9zeW5jaW5mbyA9IDB4NTU1NTU1OWQ2NDQw LCBiZV9wYiA9IDB4MCwgYmVfY2Zfb2NzID0gMHgwLCBiZV9wcml2YXRlID0gMHg1NTU1NTU4ODc4 YTAgPGNmQmFja0luZm8+LCBiZV9uZXh0ID0ge3N0cWVfbmV4dCA9IDB4NTU1NTU1OWQ3Y2EwfX0K ICAgICAgICBjYiA9IHtzY19uZXh0ID0gMHgwLCBzY19yZXNwb25zZSA9IDB4NTU1NTU1NWZhNTQw IDxvdmVyX2JhY2tfcmVzcG9uc2U+LCBzY19jbGVhbnVwID0gMHgwLCBzY193cml0ZXdhaXQgPSAw eDAsIHNjX3ByaXZhdGUgPSAweDU1NTU1NTlkNDdkMH0KICAgICAgICBzYyA9IDxvcHRpbWl6ZWQg b3V0PgogICAgICAgIHJjID0gMzI3NjgKICAgICAgICBfX1BSRVRUWV9GVU5DVElPTl9fID0gIm92 ZXJfb3BfZnVuYyIKIzExIDB4MDAwMDU1NTU1NTVhNTY4NCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4 N2ZmZmEwMTJkNDAwLCBycz0weDdmZmZhZDA0Yzk4MCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9z bGFwZC9tb2RpZnkuYzozMDMKICAgICAgICB1cGRhdGUgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICByZXBsX3VzZXIgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvcF9iZSA9IDxvcHRpbWl6ZWQg b3V0PgogICAgICAgIGJkID0gMHg1NTU1NTU4ODkzYzAgPHNsYXBfZnJvbnRlbmREQj4KICAgICAg ICB0ZXh0YnVmID0gIlwzNDBGXDI3MlwzNjdcMzc3XDE3N1wwMDBcMDAwXHZcdlwwMDBcMjQwXDM3 N1wxNzdcMDAwXDAwMFwwMDNcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwXDM2MUpcMjcyXDM2 N1wzNzdcMTc3XDAwMFwwMDBcMDAwXDI3MFwwMDRcMjU1XDM3N1wxNzdcMDAwXDAwMFwyMDBcMjcw XDAwNFwyNTVcMzc3XDE3N1wwMDBcMDAwXDAwNlwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBc MDAwXDM0M1wzNDNcMzYzXDMyMVwwMzYvXDM3NFwyMDBcMjcwXDAwNFwyNTVcMzc3XDE3N1wwMDBc MDAwXDIwMFxuXDAwMFwyNDBcMzc3XDE3N1wwMDBcMDAwXDIwMFwyNzBcMDA0XDI1NVwzNzdcMTc3 XDAwMFwwMDBcMDIwXDAwMVwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwNzBcMzI0XDAyMlwyNDBc Mzc3XDE3N1wwMDBcMDAwXDAwMFwzNDNcMzQzXDM2M1wzMjFcMDM2L1wzNzRcMDM1XDAwMFwwMDBc MDAwXDAwMFwwMDBcMDAwXDAwMFwyMDBcMjUzXDAyMlwyNDBcMzc3XDE3N1wwMDBcMDAwXDIwMFwz MTFcMDA0XDI1NVwzNzdcMTc3XDAwMFwwMDBgXDI1M1wwMjJcMjQwXDM3N1wxNzciLCAnXDAwMCcg PHJlcGVhdHMgMTggdGltZXM+LCAiXDAwNFwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMjQ1 ZVpVVVVcMDAwXDAwMFwzMjBcMzEzXDAwNFwyNTVcMzc3XDE3N1wwMDBcMDAwXDI2MFwyNzBcMDA0 XDI1NVwzNzdcMTc3XDAwMFwwMDBcMjQwXDMxMVwwMDRcMjU1XDM3N1wxNzdcMDAwXDAwMCIuLi4K IzEyIDB4MDAwMDU1NTU1NTVhNzZiYiBpbiBkb19tb2RpZnkgKG9wPTB4N2ZmZmEwMTJkNDAwLCBy cz0weDdmZmZhZDA0Yzk4MCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9tb2RpZnkuYzox NzcKICAgICAgICBkbiA9IHtidl9sZW4gPSAyOCwgYnZfdmFsID0gMHg3ZmZmYTAxMmNmMzcgIm9s Y0RhdGFiYXNlPXsxfW1kYixjbj1jb25maWcifQogICAgICAgIHRleHRidWYgPSAiUFwzMzBcMDIy XDI0MFwzNzdcMTc3XDAwMFwwMDBcMDY1XDAzMVwzNDVcMzYzXDM3N1wxNzdcMDAwXDAwMFwzMTVc MzcxXDM1NWM2XDM2Mi1fX2kkXDM2Ntm9XDI3N1wyMDc8XDM1MEE4ZVwzNTVNXDM3MFwzNTAkdlwy MjRqU1wyNzNcMjE3XDI1MFwzNzdcMDYwITZcMjE3XDI1ND5cMDAwXDM0MlwyMzE+XDAyMW5cMjU0 XDAxN9moe1wwMjNcMDIzQUdcMDI0Q1wyMjJcMzc1IFwzNDRcMDcwXDMyN1wyNzdWXDIyMlwyNzBc MjIxS2NPdT5vXDAwM8mWy7oxXDMzMSVrXDI2NlwyMTFcMzEyXDA2NVwyNTdcMDAwXDAyNFwyMzJc MjIyRilxXDIxN8mjXGFcMDE2XDIwNlwwNjZcMjMyXDIyMlNzXDI0NlwzNTVcMzExeFwwMjJcMzE3 ZFwzNjR3XDMyMypcMjUzXDM3NlNcMDMzXDM2NGlcMzE2XDM3NmJcMjI0XDMzMNq6I316XDM0Mlwz MTZIcy9cMzQxU1wzMTZGXDMwNVdMJVwzNDdcMDMzXDM2Ny9cMjY1SVwyMjZAUFZcMjI1XDM2NmFc MjQ1XDAzMFwzMDBcMzExXtSKXDAwNUtcMDMwQlwyMTdcMDYyblwyMTUrQ1wzMDBcYlwwMDBcMjMw XDM3N1wxNzdcMDAwXDAwMFwzMzRcMzYyXDI3M1wzNjdcMzc3XDE3N1wwMDBcMDAwIi4uLgogICAg ICAgIHRtcCA9IDB4MAojMTMgMHgwMDAwNTU1NTU1NThkYTI2IGluIGNvbm5lY3Rpb25fb3BlcmF0 aW9uIChjdHg9Y3R4QGVudHJ5PTB4N2ZmZmFkMDRjYmQwLCBhcmdfdj1hcmdfdkBlbnRyeT0weDdm ZmZhMDEyZDQwMCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jb25uZWN0aW9uLmM6MTE1 NQogICAgICAgIHJjID0gODAKICAgICAgICBjYW5jZWwgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICBvcCA9IDB4N2ZmZmEwMTJkNDAwCiAgICAgICAgcnMgPSB7c3JfdHlwZSA9IFJFUF9SRVNVTFQs IHNyX3RhZyA9IDAsIHNyX21zZ2lkID0gMCwgc3JfZXJyID0gMCwgc3JfbWF0Y2hlZCA9IDB4MCwg c3JfdGV4dCA9IDB4MCwgc3JfcmVmID0gMHgwLCBzcl9jdHJscyA9IDB4MCwgc3JfdW4gPSB7c3J1 X3NlYXJjaCA9IHtyX2VudHJ5ID0gMHgwLCByX2F0dHJfZmxhZ3MgPSAwLCByX29wZXJhdGlvbmFs X2F0dHJzID0gMHgwLCByX2F0dHJzID0gMHgwLCAKICAgICAgICAgICAgICByX25lbnRyaWVzID0g MCwgcl92MnJlZiA9IDB4MH0sIHNydV9zYXNsID0ge3Jfc2FzbGRhdGEgPSAweDB9LCBzcnVfZXh0 ZW5kZWQgPSB7cl9yc3BvaWQgPSAweDAsIHJfcnNwZGF0YSA9IDB4MH19LCBzcl9mbGFncyA9IDB9 CiAgICAgICAgdGFnID0gMTAyCiAgICAgICAgb3BpZHggPSBTTEFQX09QX01PRElGWQogICAgICAg IGNvbm4gPSAweDU1NTU1NWExODZmMAogICAgICAgIG1lbWN0eCA9IDB4N2ZmZmEwMDAwOGMwCiAg ICAgICAgbWVtY3R4X251bGwgPSAweDAKICAgICAgICBtZW1zaXogPSAxMDQ4NTc2CiAgICAgICAg X19QUkVUVFlfRlVOQ1RJT05fXyA9ICJjb25uZWN0aW9uX29wZXJhdGlvbiIKIzE0IDB4MDAwMDU1 NTU1NTU4ZGQzYSBpbiBjb25uZWN0aW9uX3JlYWRfdGhyZWFkIChjdHg9MHg3ZmZmYWQwNGNiZDAs IGFyZ3Y9MHgxNikgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jb25uZWN0aW9uLmM6MTI5 MQogICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgY3JpID0ge29wID0gMHg3ZmZm YTAxMmQ0MDAsIGZ1bmMgPSAweDAsIGFyZyA9IDB4MCwgY3R4ID0gMHg3ZmZmYWQwNGNiZDAsIG51 bGxvcCA9IDxvcHRpbWl6ZWQgb3V0Pn0KICAgICAgICBzID0gMjIKIzE1IDB4MDAwMDdmZmZmN2I5 NDNhMiBpbiA/PyAoKSBmcm9tIC91c3IvbGliL3g4Nl82NC1saW51eC1nbnUvbGlibGRhcF9yLTIu NC5zby4yCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE2IDB4MDAwMDdmZmZmNmFj YTZiYSBpbiBzdGFydF90aHJlYWQgKGFyZz0weDdmZmZhZDA0ZDcwMCkgYXQgcHRocmVhZF9jcmVh dGUuYzozMzMKICAgICAgICBfX3JlcyA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHBkID0gMHg3 ZmZmYWQwNGQ3MDAKICAgICAgICBub3cgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICB1bndpbmRf YnVmID0ge2NhbmNlbF9qbXBfYnVmID0ge3tqbXBfYnVmID0gezE0MDczNjA5NjE2MzU4NCwgLTQ5 MDIxMTgzNjcwNTgyOTI4NSwgMCwgMTQwNzM3MTg4NzgxMzI3LCAxNDA3MzYwOTYxNjQyODgsIDkz ODI0OTk2OTc4NjI0LCA0OTAxMDE3MDM1MjE0MDY1NTUsIDQ5MDE5NzE1Nzc5OTcyNjY4M30sIG1h c2tfd2FzX3NhdmVkID0gMH19LCBwcml2ID0ge3BhZCA9IHsweDAsIDB4MCwgMHgwLCAKICAgICAg ICAgICAgICAweDB9LCBkYXRhID0ge3ByZXYgPSAweDAsIGNsZWFudXAgPSAweDAsIGNhbmNlbHR5 cGUgPSAwfX19CiAgICAgICAgbm90X2ZpcnN0X2NhbGwgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICBwYWdlc2l6ZV9tMSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHNwID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgZnJlZXNpemUgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBfX1BSRVRUWV9G VU5DVElPTl9fID0gInN0YXJ0X3RocmVhZCIKIzE3IDB4MDAwMDdmZmZmNjgwMDNkZCBpbiBjbG9u ZSAoKSBhdCAuLi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC94ODZfNjQvY2xvbmUuUzoxMDkKTm8g bG9jYWxzLgo= --001a113c349ed7ce5c0554434d63--

1 0

(ITS#8693) slaptest conversion of chain overlay generates invalid or undocumented starttls parameter
by jckidder＠aep.com 13 Jul '17

13 Jul '17

Full_Name: Jon Kidder Version: 2.4.44 OS: RHEL 6.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.239.221.87) This .conf section overlay chain chain-uri "ldaps://<myhost>" chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="<myuser>" credentials=<mycreds> mode="self" chain-tls ldaps tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error TRUE becomes this ldap backend when using slaptest # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 bdc4cf96 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldaps://<myhost>" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tl s/cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bin dmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,ou=automaton s,ou=users,dc=global,dc=aep,dc=com" credentials=<mycreds> keepalive=0:0:0 olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: 7b1cc741-120e-4ce2-b539-17791a361cb1 creatorsName: cn=config createTimestamp: 20170707202053Z entryCSN: 20170707202053.340477Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170707202053Z The starttls parameter of the chain-tls/tls/olcDBStartTLS attribute is either invalid or undocumented.

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message (unsigned)
by michael＠stroeder.com 12 Jul '17

12 Jul '17

(Re-sent without S/MIME sign. for better readability in ITS) This seems really trivial to fix - even for me. ;-) I've successfully tested it with Python module slapdsock (and ldif module in python-ldap 2.4.41+). I, Michael Ströder, 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. https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-incremen… --------------------------------------------------------------------------------------- >From 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michael=20Str=C3=B6der?= <michael(a)stroeder.com> Date: Wed, 12 Jul 2017 20:18:22 +0200 Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case of LDAP_MOD_INCREMENT (see RFC 4525, section 3) --- servers/slapd/back-sock/modify.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/modify.c index c35d31bc6..9342d2702 100644 --- a/servers/slapd/back-sock/modify.c +++ b/servers/slapd/back-sock/modify.c @@ -85,6 +85,10 @@ sock_back_modify( case LDAP_MOD_REPLACE: fprintf( fp, "replace: %s\n", mod->sm_desc->ad_cname.bv_val ); break; + + case LDAP_MOD_INCREMENT: + fprintf( fp, "increment: %s\n", mod->sm_desc->ad_cname.bv_val ); + break; } if( mod->sm_values != NULL ) { -- 2.13.2

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 12 Jul '17

12 Jul '17

This is a cryptographically signed message in MIME format. --------------ms070903000906000403080407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems really trivial to fix - even for me. ;-) I've successfully tested it with Python module slapdsock (and ldif module= in python-ldap 2.4.41+). I, Michael Str=C3=B6der, hereby place the following modifications to Open= LDAP Software (and only these modifications) into the public domain. Hence, these modificati= ons may be freely used and/or redistributed for any purpose with or without attribut= ion and/or other notice. https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-increm= ent-line.patch -------------------------------------------------------------------------= -------------- =46rom 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Michael=3D20Str=3DC3=3DB6der?=3D <michael(a)stroeder.com>= Date: Wed, 12 Jul 2017 20:18:22 +0200 Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case = of LDAP_MOD_INCREMENT (see RFC 4525, section 3) --- servers/slapd/back-sock/modify.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/m= odify.c index c35d31bc6..9342d2702 100644 --- a/servers/slapd/back-sock/modify.c +++ b/servers/slapd/back-sock/modify.c @@ -85,6 +85,10 @@ sock_back_modify( case LDAP_MOD_REPLACE: fprintf( fp, "replace: %s\n", mod->sm_desc->ad_cname.bv_val ); break; + + case LDAP_MOD_INCREMENT: + fprintf( fp, "increment: %s\n", mod->sm_desc->ad_cname.bv_val ); + break; } if( mod->sm_values !=3D NULL ) { --=20 2.13.2 --------------ms070903000906000403080407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzEyMTkzOTAzWjAvBgkq hkiG9w0BCQQxIgQgnqI1DvtHUweHIV0AnS/gA0/OrfIjpb0PVNDvi75eNPIwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAhXv2pTJgL9mLTUlPradGexdRjNYJdGGamEarwi2KXfmhcc4KDuZJvmWE8hF81lkjvgdU +3UOC9jWqG90NHexCexcswnHkQ0igrc8KYUFQhgAFsWOMsCkAmnzu02zQcgcIIJDarbOOCKG 0tZZ+1FzXeqB3ii1Uj9NJv6Sv/BgmJGU0XivlL9QAMtMylbJJnlBDeoqKC3Ti7PgJDkn0VuP gvR20a732AM4eZyzreKhg0qx6Tiaaw6vSYcFxsaffsKL5s3GuRx5uPUnDINGnbCFA1OVi+BA dq1819pvcrAmpYDvgMXgI+Mo/alvPLRzDn2pDdt8G7IBG7/UkFtvI7UDFwAAAAAAAA== --------------ms070903000906000403080407--

1 0

(ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 12 Jul '17

12 Jul '17

Full_Name: Version: OS: URL: Submission from: (NULL) (85.115.23.42) back-sock does not generate a MODIFY message with "increment:" line when LDAP clients sends modify operation with LDAP_MOD_INCREMENT. Example of incomplete message (incrementing attribute gidNumber): ----------------------------- snip ----------------------------- MODIFY msgid: 119 binddn: uid=msin,cn=ae,ou=ae-dir peername: PATH=/usr/local/openldap/var/run/ldapi ssf: 256 connid: 1025 suffix: ou=ae-dir dn: ou=ae-dir gidNumber: 1 - ----------------------------- snip -----------------------------

1 0

Re: (ITS#8690) syncprov memory leak
by quanah＠symas.com 11 Jul '17

11 Jul '17

--On Tuesday, July 11, 2017 1:25 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) Better trace: ==1504== 20,123 bytes in 67 blocks are definitely lost in loss record 40 of 41 ==1504== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1504== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==1504== by 0x464A88: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==1504== by 0x962B849: syncprov_qresp (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1062) ==1504== by 0x962F22C: syncprov_op_response (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1982) ==1504== by 0x454227: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==1504== by 0x45449A: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==1504== by 0x455509: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==1504== by 0x984BBEF: bdb_delete (/home/build/git/sold-2445/openldap/servers/slapd/back-bdb/delete.c:596) ==1504== by 0x4D9968: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==1504== by 0x4D9BBA: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==1504== by 0x4D9D9B: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==1504== by 0x4623FF: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==1504== by 0x462037: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==1504== by 0x43D4E4: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==1504== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==1504== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==1504== ==1504== 220,540 bytes in 734 blocks are definitely lost in loss record 41 of 41 ==1504== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1504== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==1504== by 0x464A88: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==1504== by 0x962B849: syncprov_qresp (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1062) ==1504== by 0x962F22C: syncprov_op_response (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1982) ==1504== by 0x454227: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==1504== by 0x45449A: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==1504== by 0x455509: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==1504== by 0x984BBEF: bdb_delete (/home/build/git/sold-2445/openldap/servers/slapd/back-bdb/delete.c:596) ==1504== by 0x4D9968: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==1504== by 0x4D9BBA: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==1504== by 0x4D9D9B: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==1504== by 0x4623FF: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==1504== by 0x462037: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==1504== by 0x43D4E4: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==1504== by 0x43DB8A: connection_read_thread (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1294) ==1504== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==1504== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==1504== --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8691) slapd crashes during shutdown
by derrick.mckee＠gmail.com 11 Jul '17

11 Jul '17

Full_Name: Derrick McKee Version: OPENLDAP_REL_ENG_2_4_45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2404:f801:8028:1::17f) Compiling OpenLDAP using clang on Windows with MinGW results in a binary that crashes during shutdown. The issue is with mdb_txn_abort in libraries/liblmdb/mdb.c. The initial txn does have a non-null child, however, the address is a garbage address (i.e. containing a mix of 1 and 0 bits set in the upper 16 bits in a 64-bit pointer). This seems to indicate that somewhere the code is expecting a 0 initialized memory area, when it isn't. How to recreate: CC=clang CFLAGS="-m64" ./configure --without-threads --without-tls make depend && make (using CMD.exe) ./servers/slapd/slapd <user hits Ctrl-c>

1 0

(ITS#8690) syncprov memory leak
by quanah＠openldap.org 11 Jul '17

11 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Setting up a 2-node MMR pair, using standard syncrepl in refreshAndPersist mode, shows there is a steady leak in syncprov on the master receiving write traffic. Output from mleak: Memory leaks (498370 total): Leak, blocks, size: 0x7f2910103d80,933,280319 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) slapd : connection_read_thread (connection.c:1294) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0x7f29101015b0,671,201605 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0xd648a0,1,1560 realloc (mleak.c:293) stack: libc.so.6 : ?? (<unknown_file>:0) slapd : slap_get_listener_addresses (daemon.c:1179) slapd : slap_open_listener (daemon.c:1362) slapd : slapd_daemon_init (daemon.c:1682) slapd : main (main.c:740) libc.so.6 : ?? (<unknown_file>:0) slapd : _start (??:0) Output from valgrind: ==3926== 79,998 bytes in 266 blocks are definitely lost in loss record 20 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926== ==3926== 401,025 bytes in 1,335 blocks are definitely lost in loss record 21 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x43DBCA: connection_read_thread (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1294) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926==

1 0

(ITS#8689) invalid rwm configuration causes slapd to SEGV
by quanah＠openldap.org 10 Jul '17

10 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If you incorrectly configure slapo-rwm so that it has an invalid mapping, slapd will crash after a search is performed against the mapped base. For example: rwm-rewriteRule "(.+,)?dc=example2,[ ]?dc=com$" "$1dc-example, dc=com" rwm-rewriteRule "(.+,)?dc=example2,dc=com$" "$1dc-example,dc=com" (note that it has dc-example,dc=com instead of dc=example,dc=com) It might be helpful? to parse the rewrite rules for validity, but that may be difficult to do. Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fcd66999700 (LWP 844)] slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 515 /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c: No such file or directory. (gdb) bt #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7fcd66999700 (LWP 844)): #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 nextp = 0x6520e534bd7384d0 size = 7286935691776455520 p = 0x7fcd5c001170 tmpp = <optimized out> ctx = 0x7fcd5c000a80 ptr = 0x7fcd5c001178 sh = 0x7fcd5c000a80 p = 0x7fcd5c001178 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 base = {bv_len = 18, bv_val = 0x7fcd58000a87 "dc=example2,dc=com"} siz = 0 off = <optimized out> i = <optimized out> #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 rc = 80 cancel = <optimized out> op = 0x7fcd580028d0 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = -1, sr_matched = 0x0, sr_text = 0x7fcda7ba945d "searchDN massage error", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7fcdac7e5b90 memctx = 0x7fcd5c000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x7fcd600008c0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520166364928, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd5c000970, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd5c000a80, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd5c000b70, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd66999700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520166364928, 1493515270220219122, 0, 140520183139599, 140520166365632, 4391152, -1503985625800834318, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 3 (Thread 0x7fcd6719a700 (LWP 843)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007fcdac4fcc65 in ldap_pvt_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:277 No locals. #2 0x00007fcdac4fc45f in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:945 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520174757632, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd580026a0, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd580027b0, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd58002d10, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6719a700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6719a700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520174757632, 1493515270220219122, 0, 140520183139647, 140520174758336, 4370320, -1503984526826077454, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #4 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 2 (Thread 0x7fcd6799b700 (LWP 804)): #0 0x00007fcdab1289d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 No locals. #1 0x000000000042b7c0 in slapd_daemon_task (ptr=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2539 ns = <optimized out> at = <optimized out> nfds = <optimized out> revents = 0x26c0ff0 tvp = 0x0 cat = {tv_sec = 0, tv_usec = 0} i = <optimized out> nwriters = <optimized out> now = <optimized out> tv = {tv_sec = 0, tv_usec = 0} tdelta = 1 rtask = <optimized out> l = <optimized out> last_idle_check = 1499703215 ebadf = 0 tid = 0 #2 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6799b700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6799b700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520183150336, 1493515270220219122, 0, 140735119107759, 140520183151040, 0, -1503983425703836942, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #3 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 1 (Thread 0x7fcdac957700 (LWP 803)): #0 0x00007fcdac0c698d in pthread_join (threadid=140520183150336, thread_return=thread_return@entry=0x0) at pthread_join.c:90 __tid = 804 _buffer = {__routine = 0x7fcdac0c68b0 <cleanup>, __arg = 0x7fcd6799bd28, __canceltype = 0, __prev = 0x0} oldtype = 0 pd = 0x7fcd6799b700 self = 0x7fcdac957700 result = 0 #1 0x00007fcdac4fcbf5 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:197 No locals. #2 0x000000000042d529 in slapd_daemon () at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2932 i = 0 rc = 0 #3 0x0000000000415261 in main (argc=7, argv=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/main.c:1016 i = <optimized out> no_detach = 0 urls = 0x26ae0d0 "ldap:///" username = 0x26ae090 "EXTERNAL" groupname = 0x26ae0b0 "\006\362\032\253\315\177" sandbox = 0x0 syslogUser = 160 pid = <optimized out> waitfds = {9, 10} g_argc = 7 g_argv = <optimized out> configfile = 0x0 configdir = 0x0 serverName = 0x7fff72c838fe "slapd" scp = <optimized out> scp_entry = <optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = <synthetic pointer> l = <optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <optimized out> __PRETTY_FUNCTION__ = "main"

1 0

(ITS#8686)
by yoshiho.yoshida＠synacor.com 10 Jul '17

10 Jul '17

I reported the caluculation of the size of original and normalized rdn is as follows. > len_rdn is the size of original rdn. > len_norm_rdn is the size of normalized rdn. > > ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) But after the test about verious sizes of rdn, the above calculation does not cover the all cases and the next simple calculation should match more verious sizes. len_rdn + 3 > len_norm_rdn x 2 -- Yoshiho Yoshida This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca 08 Jul '17

08 Jul '17

On Fri, Jul 07, 2017 at 06:20:55AM +0000, ryan(a)nardis.ca wrote: >Unpacking the computation, it looks like the multiplication is the part >that sometimes returns the wrong result. Not the multiplication, but rather the cast of nvalues to double. I'm going to take further followups to the Debian tracker, as it seems fairly clear to me that this is not an OpenLDAP bug.

1 0

Re: (ITS#8688) Is it possible to control on the failover of backend LDAP?
by quanah＠symas.com 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:56 PM +0000 meheni.ziani(a)gmail.com wrote: > Is there a way to close open connections in LDAP1 when the proxy switches > to the LDAP2? Hello, The ITS system is for bug reports only. Usage questions are to be directed to the openldap-technical(a)openldap.org mailing list. As this is not a bug report, this ITS will be closed. Please send your question(s) to the openldap-technical list. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8688) Is it possible to control on the failover of backend LDAP?
by meheni.ziani＠gmail.com 07 Jul '17

07 Jul '17

Full_Name: Meheni Version: 2.4.44 OS: CentOs 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.116.6.97) Hello, We have implemented two "OpenLDAP mirror directory": ldaps://ldap1 and ldaps://ldap2 (version 2.4.44) and an LDAP proxy with back_ldap + overlay pcache (version 2.4.44). We want to understand two behaviors found on the LDAP proxy: 1 - We dont succeed to control failover switch between 2 backend LDAP by proxy OpenLDAP. The proxy passes too quickly due to a micro-cutter (for example, a one-second cut). We want to know if there is a way that we can better control the switchover too fast. 2 - We found that when the proxy goes to the second URI (ldaps: // ldap2) (because of a network break of a few seconds), the open connections on the first directory do not close. Besides, when LDAP1 is back, the new requests with the old connection will be arrive to LDAP1 but it should be arrive to LDAP2. Therere only new requests with new connection arriving at LDAP2. Is there a way to close open connections in LDAP1 when the proxy switches to the LDAP2? kind regards, Meheni

1 0

Re: (ITS#8685) Invalid memory access
by hyc＠symas.com 07 Jul '17

07 Jul '17

Breno Leitao wrote: > Hello Howard, > > On Thu, Jul 06, 2017 at 08:55:01PM +0100, Howard Chu wrote: >> leitao(a)debian.org wrote: >>> Full_Name: Breno Leitao >>> Version: upstream >>> OS: Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (32.104.18.202) >>> >>> >>> Currently, do_random() function in tests/progs/slapd-mtread.c uses a random >>> number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, >>> causing a segfault. >>> >>> This causes a segmentation fault and more details could be found at >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 >>> >>> >> Thanks for the report. I've examined your proposed patch in your debian >> bugtracker. It doesn't make much sense though. >> >> The random number is being correctly scaled, line 682: >> >> int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); >> >> Which means the value of r can only be from 0 to nvalues-1. >> >> And there should be no difference between nvalues and i, since on line 657: >> >> nvalues = ldap_count_entries( ld, res ); >> >> Since i is simply iterated through all of the entries in the response, the >> two values cannot disagree. > > Thanks for looking at it, and your suggestion made me revisit it. let me > share I am finding in the debug. This is the failure frame: You cannot possibly diagnose this with an optimized binary. You're missing several crucial variables. Your analysis here is completely invalid. > > #5 do_read (ld=0x3fff980008e0, entry=0x6e6d756c413d756f <error: Cannot access memory at address 0x6e6d756c413d756f>, > attrs=0x20020058 <srchattrs>, noattrs=<optimized out>, maxloop=<optimized out>, maxretries=<optimized out>, force=<optimized out>, > idx=<optimized out>, chaserefs=<optimized out>, delay=<optimized out>, nobind=<optimized out>) at ../../../../tests/progs/slapd-mtread.c:791 > > On this frame, these are the values we have: > > i = 0 > do_retry = 0 > rc = <optimized out> > thrstr = "Read(1): entry=\"0 cnt: 1 (retried 0) (dc=example,dc=com)\000u=Alumni Association,ou=People,dc=example,dc=com)\000mple,dc=com)", '\000' <repeats 6641 times>... > e = <optimized out> > attrs = {0x200072a0 "1.1", 0x0} > rc = 0 > nvalues = <optimized out> > res = 0x3fffa0001ac0 -- -- 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#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by djkurtz＠google.com 07 Jul '17

07 Jul '17

Full_Name: Daniel Jonathan Kurtz Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) openldap 2.4.45 fails to link when built against openssl 1.1 built w/ the default "no-egd" option: libtool: link: x86_64-cros-linux-gnu-clang -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -clang-syntax -Wl,-O1 -Wl,-O2 -Wl,--as-needed -o .libs/ltest test.o ./.libs/libldap.so libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv ./.libs/libldap.so: error: undefined reference to 'RAND_egd' RAND_egd does not exist because OpenSSL was built with the default settings which, as of 1.1, has "EGD" disabled by default [0]. [0] 0423f812dc Add a no-egd option to disable EGD-related code *) EGD is no longer supported by default; use enable-egd when configuring. [Ben Kaduv and Rich Salz] The RAND_egd reference is in libraries/libldap/tls_o.c: static int tlso_seed_PRNG( const char *randfile ) { #ifndef URANDOM_DEVICE /* no /dev/urandom (or equiv) */ long total=0; char buffer[MAXPATHLEN]; if (randfile == NULL) { /* The seed file is $RANDFILE if defined, otherwise $HOME/.rnd. * If $HOME is not set or buffer too small to hold the pathname, * an error occurs. - From RAND_file_name() man page. * The fact is that when $HOME is NULL, .rnd is used. */ randfile = RAND_file_name( buffer, sizeof( buffer ) ); } else if (RAND_egd(randfile) > 0) { /* EGD socket */ return 0; } if (randfile == NULL) { Debug( LDAP_DEBUG_ANY, "TLS: Use configuration file or $RANDFILE to define seed PRNG\n", 0, 0, 0); return -1; } ... It seems like we should be able to make the "else if (RAND_egd(randfile) > 0)" block conditional on "#if !defined(OPENSSL_NO_EGD)" to work around this issue

1 0

(ITS#8686) modrdn can't find the target dn if it is read directly from hdb backend
by yoshiho.yoshida＠synacor.com 07 Jul '17

07 Jul '17

Full_Name: Yoshiho Yoshida Version: 2.4.44 OS: CentOS 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.237.186.4) This issue only happens with hdb back-end database. If the target dn is not in the cache memory, then modrdn tries to get it from hdb using its normalized rdn. As this result, modrdn can't find the target dn with "No such attribute (16)" or "No such object (32)" error. no cache --> dn2id.bdb -- id --> id2entry.bdb The problem seems to exist in the buffer size to get id from dn2id.bdb. Test case uses uid as rdn and its syntax is SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} . Then this normalize is, 1) Normalization of UTF-8 (NKFC mormalization) 2) consecutive space characters to a single space 3) trim the ending space If the size of original rdn and normalized rdn is as follows, this problem occurs. len_rdn is the size of original rdn. len_norm_rdn is the size of normalized rdn. ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) Test case: 1. Test data $ cat zzz.ldif dn: dc=zzz dc: zzz objectClass: dcObject objectClass: organization o: zzz domain $ cat yyy.ldif dn: dc=yyy,dc=zzz o: yyy.zzz domain objectClass: dcObject objectClass: organization dc: yyy $ cat people.ldif dn: ou=people,dc=yyy,dc=zzz ou: people objectClass: organizationalRole cn: people $ cat xxx.ldif dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 2. Add the above test data into ldap database (hdb) $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f zzz.ldif ldap_initialize( ldap://192.168.10.131 ) add dc: zzz add objectClass: dcObject organization add o: zzz domain adding new entry "dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f yyy.ldif ldap_initialize( ldap://192.168.10.131 ) add o: yyy.zzz domain add objectClass: dcObject organization add dc: yyy adding new entry "dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f people.ldif ldap_initialize( ldap://192.168.10.131 ) add ou: people add objectClass: organizationalRole add cn: people adding new entry "ou=people,dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f xxx.ldif ldap_initialize( ldap://192.168.10.131 ) add sn: xxx add cn: xxx add uid: xxx add objectClass: inetOrgPerson adding new entry "uid=xxx,ou=people,dc=yyy,dc=zzz" modify complete $ o Verify the added dn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password uid=xxx version: 1 dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 3. modify the above dn (rdn) $ cat modrdn_1.ldif uid=xxx,ou=people,dc=yyy,dc=zzz uid=\20a $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_1.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=xxx,ou=people,dc=yyy,dc=zzz" new rdn="uid=\20a" (delete old rdn) Rename Result: Success (0) $ o Verify the changed rdn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ o Start the recurrence test 4. Restart the slapd to remove the cache $ ldap stop Killing slapd with pid 15740 done. $ $ tail /var/log/zimbra.log Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1002 fd=18 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1003 fd=20 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1004 fd=22 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1005 fd=24 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd shutdown: waiting for 0 operations/tasks to finish Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd stopped. $ $ ldap start Started slapd: pid 16998 $ $ tail /var/log/zimbra.log Jul 7 12:54:58 jpzcserv1 slapd[16997]: @(#) $OpenLDAP: slapd 2.4.44 (May 30 2017 23:19:56) $#012#011root@jpzcserv1.zimbra.jp:/home/yyoshida/zimbra/work/OpenLDAP_244/openldap-2.4.44/servers/slapd Jul 7 12:54:58 jpzcserv1 slapd[16998]: slapd starting $ 5. Then try to modify the rdn $ cat modrdn_2.ldif uid=\20a,ou=people,dc=yyy,dc=zzz uid=abc $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: No such attribute (16) Additional info: modify/delete: uid: no such attribute $ Failed with " No such attribute (16)" 6. Then search the target dn to load the entry to cache $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ 7. Again modify the same rdn $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: Success (0) $ Now it can be modified successfully. This problem found when the replica server needed to be restarted and it never synchronized with the master server because there are some bad dn data. The master server is also possible to have this problem if it needs to be restarted. Workaround) dn2id.c increase the size of data.ulen in hdb_dn2id() data.ulen = data.size * 3; d = op->o_tmpalloc( data.size * 3, op->o_tmpmemctx );

1 0

Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca 07 Jul '17

07 Jul '17

Hi Breno, Thanks a lot for taking the time to look at this. I reproduced the crash on a minicloud VM (thanks!) with gcc -O2 (but not -O1 or -O0) and also with clang -O2 and -O1 (but not -O0). On Fri, Jul 07, 2017 at 12:57:47AM +0000, leitao(a)debian.org wrote: >So, that is what I suppose is happening. On the following loop, >ldap_first_entry() is returning NULL, thus, i = 0; > > for ( i = 0, e = ldap_first_entxury( ld, res ); e != NULL; i++, e = ldap_next_entry( ld, e ) ) > { > values[ i ] = ldap_get_dn( ld, e ); > } > values[ i ] = NULL; > >Thus, value[0] = NULL; I have not been able to reproduce that. I added an assert(i == nvalues) here, but it never failed in the time I spent on this today. On IRC, Howard pointed at the computation of 'r' (line 682), and indeed some printf debugging suggests that may be going wrong. I occasionally saw values of 'r' greater than 'nvalues', leading to reads past the end of the array like you suggested. for example: nvalues = 19 [...] i=20 r=11 values[r]=0x10014fba0f0 i=48 r=6 values[r]=0x3fff40000bd0 i=49 r=3 values[r]=0x3fff40000b50 i=51 r=7 values[r]=0x3fff6c001310 i=46 r=11 values[r]=0x3fff0c003530 i=56 r=27 values[r]=0x25 Segmentation fault (core dumped) Unpacking the computation, it looks like the multiplication is the part that sometimes returns the wrong result. For example: nvalues = 19 [...] rand() -> 745824322 ((double)19)*745824322 -> 45495283642.000000 45495283642.000000 / 2147483648.000000 -> 21.185392 i=75 r=21 values[r]=0x35 Segmentation fault (core dumped) but 19.0*745824322 should be 14170662118. I'm not really sure where to look next. Compiler bug would be a nice explanation, but wouldn't it be unusual for gcc and clang to have the same bug?

1 0

Re: (ITS#8685) Invalid memory access
by leitao＠debian.org 07 Jul '17

07 Jul '17

Hello Howard, On Thu, Jul 06, 2017 at 08:55:01PM +0100, Howard Chu wrote: > leitao(a)debian.org wrote: > > Full_Name: Breno Leitao > > Version: upstream > > OS: Debian > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (32.104.18.202) > > > > > > Currently, do_random() function in tests/progs/slapd-mtread.c uses a random > > number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, > > causing a segfault. > > > > This causes a segmentation fault and more details could be found at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 > > > > > Thanks for the report. I've examined your proposed patch in your debian > bugtracker. It doesn't make much sense though. > > The random number is being correctly scaled, line 682: > > int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); > > Which means the value of r can only be from 0 to nvalues-1. > > And there should be no difference between nvalues and i, since on line 657: > > nvalues = ldap_count_entries( ld, res ); > > Since i is simply iterated through all of the entries in the response, the > two values cannot disagree. Thanks for looking at it, and your suggestion made me revisit it. let me share I am finding in the debug. This is the failure frame: #5 do_read (ld=0x3fff980008e0, entry=0x6e6d756c413d756f <error: Cannot access memory at address 0x6e6d756c413d756f>, attrs=0x20020058 <srchattrs>, noattrs=<optimized out>, maxloop=<optimized out>, maxretries=<optimized out>, force=<optimized out>, idx=<optimized out>, chaserefs=<optimized out>, delay=<optimized out>, nobind=<optimized out>) at ../../../../tests/progs/slapd-mtread.c:791 On this frame, these are the values we have: i = 0 do_retry = 0 rc = <optimized out> thrstr = "Read(1): entry=\"0 cnt: 1 (retried 0) (dc=example,dc=com)\000u=Alumni Association,ou=People,dc=example,dc=com)\000mple,dc=com)", '\000' <repeats 6641 times>... e = <optimized out> attrs = {0x200072a0 "1.1", 0x0} rc = 0 nvalues = <optimized out> res = 0x3fffa0001ac0 So, that is what I suppose is happening. On the following loop, ldap_first_entry() is returning NULL, thus, i = 0; for ( i = 0, e = ldap_first_entxury( ld, res ); e != NULL; i++, e = ldap_next_entry( ld, e ) ) { values[ i ] = ldap_get_dn( ld, e ); } values[ i ] = NULL; Thus, value[0] = NULL; Later, the do_random() code does the following loop and innerloop is 10000. for ( i = 0; i < innerloop; i++ ) { int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); do_read( ld, values[ r ], srchattrs, noattrs, nobind, 1, maxretries, delay, force, chaserefs, idx ); } Thus, independent of the r value, values[r] will have garbage, right? But I agree with you, I need to find a better patch that address this e = NULL corner case.

1 0

Re: (ITS#8685) Invalid memory access
by hyc＠symas.com 06 Jul '17

06 Jul '17

leitao(a)debian.org wrote: > Full_Name: Breno Leitao > Version: upstream > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (32.104.18.202) > > > Currently, do_random() function in tests/progs/slapd-mtread.c uses a random > number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, > causing a segfault. > > This causes a segmentation fault and more details could be found at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 > > Thanks for the report. I've examined your proposed patch in your debian bugtracker. It doesn't make much sense though. The random number is being correctly scaled, line 682: int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); Which means the value of r can only be from 0 to nvalues-1. And there should be no difference between nvalues and i, since on line 657: nvalues = ldap_count_entries( ld, res ); Since i is simply iterated through all of the entries in the response, the two values cannot disagree. Finally, such a simple bug as your patch suggests would have crashed long ago on every other machine/OS, and it has never done so. I don't believe you've identified the actual bug. -- -- 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#8685) Invalid memory access
by leitao＠debian.org 06 Jul '17

06 Jul '17

Full_Name: Breno Leitao Version: upstream OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (32.104.18.202) Currently, do_random() function in tests/progs/slapd-mtread.c uses a random number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, causing a segfault. This causes a segmentation fault and more details could be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122

1 0

(ITS#8684) compiling 2.4.45 under AIX 7.1 fails
by huy.nguyen＠cegdim-activ.com 06 Jul '17

06 Jul '17

Full_Name: Huy Nguyen Version: 2.4.45 OS: AIX 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.6.223.9) After running configure and make depend, make fails with the following message : ./../../../libraries/liblmdb/mdb.c:4853:53: error: 'PTHREAD_MUTEX_ROBUST' undeclared (first use in this function) if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); It appears AIX 7?1 doesn't have robust mutexes (https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.genpr…). Disabling robust mutexes with CPPFLAGS="-DMDB_USE_ROBUST=0" works fine.

1 0

(ITS#8683) SLAPD_META_CLIENT_PR hidden behind LDAP_DEVEL
by quanah＠openldap.org 05 Jul '17

05 Jul '17

Full_Name: Quanah Gibson-Mount Version: RE24 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The back-meta(5) man page discusses the following option: client-pr {accept-unsolicited|DISABLE|<size>} This feature allows one to use RFC 2696 Paged Results control when performing search operations with a specific target, irrespective of the client's request. When set to a numeric value, Paged Results control is always used with size as the page size. When set to accept-unsolicited, unsolicited Paged Results control responses are accepted and honored for compatibility with broken remote DSAs. The client is not exposed to paged results handling between slapd-meta(5) and the remote servers. By default (disabled), Paged Results control is not used and responses are not accepted. If set before any target specification, it affects all targets, unless overridden by any per-target directive. However, this feature is actually disabled by default, as it is #ifdef'd behind LDAP_DEVEL in back-meta.h: #ifdef LDAP_DEVEL #define SLAPD_META_CLIENT_PR 1 #endif /* LDAP_DEVEL */ So we need to determine if either: (a) The documentation should be removed from the man page, or (b) The feature should be enabled by default, and moved out from behind LDAP_DEVEL

1 0

(ITS#8682) Malformatted man pages on AIX and Solaris
by goran.hammarback＠foxt.com 05 Jul '17

05 Jul '17

Full_Name: G.ran Hammarb.ck Version: 2.4.45 OS: AIX and Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.71.43.2) Man pages are incorrectly formatted on AIX and Solaris. The problem is that the .BR directive only takes 6 arguments on these platforms and some man pages (.e.g ldapadd.1, ldapmodify.1 and ldapsearch.1) use more arguments. It is known to affect the options -s, -a, -e and -E. For example, in ldapsearch.1, the line .BR \-s \ { base \||\| one \||\| sub \||\| children }] will be formatted as: -s {base|sub| The fix is to break up the line in ldapsearch.1 as e.g: .BR \-s \ {\c .BR base \||\| one \||\|\c .BR sub \||\| children }]

1 0

(ITS#8681) dynlist overlay fails to generate attributes when paging is used
by jengelh＠inai.de 30 Jun '17

30 Jun '17

Full_Name: Jan Engelhardt Version: 2.4.44, 2.4.45 OS: Linux 4.11, openSUSE Tumbleweed 20170626 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.178.174.83) I observed that the dynlist overlay fails to generate its attributes for certain DNs. Ultimately it appears to relate to the chosen page size with which the database is queried; the smaller, the more often it occurs. Reproduce as follows: 1. Set up dynlist in slapd.conf for the database: include rfc2307bis.schema include dyngroup.schema database hdb suffix o=da index objectClass eq rootdn cn=root,o=da overlay dynlist dynlist-attrset posixAccount labeledURI memberOf 2. Construct some entries, such as: dn: cn=users,o=da member: uid=foo,o=da cn: users objectClass: groupOfNames objectClass: top objectClass: posixGroup gidNumber: 1555 description: users memberUid: foo dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) 3. Query database with a sufficiently small page size: ## ldapsearch -xb o=da -E pr=1 dn: o=da [ a little trimmed for brevity] control: 1.2.840.113556.1.4.319 false MA0CAQAECAEAAAAAAAAA pagedresults: cookie=AQAAAAAAAAA= dn: cn=root,o=da [] pagedresults: cookie=AgAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: cn=users,o=da [] pagedresults: cookie=CAAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo Beyond givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) # search result search: 5 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= With larger pagesizes or completely omitting -E pr, memberOf does appear: labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) memberOf: cn=users,o=da

1 0

Re: (ITS#8680) OpenLDAP 2.4.45 for Windows
by quanah＠symas.com 30 Jun '17

30 Jun '17

--On Friday, June 30, 2017 2:12 PM +0000 muthamma.appaiah(a)wellsfargo.com wrote: > Full_Name: Svetlana > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::c) > > > Hi team, > > Could you please help us with the source file of 2.4.45 for Windows > operating system from your website? Hello, The ITS system is for reporting bugs with the OpenLDAP software. It is not the proper location for asking for help. If you need assistance with compiling OpenLDAP on Windows, the correct forum for asking for that help would be the openldap-technical(a)openldap.org list. Alternatively, I would note that my company (Symas) provides pre-built binaries of OpenLDAP for Windows with options for support. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8680) OpenLDAP 2.4.45 for Windows
by muthamma.appaiah＠wellsfargo.com 30 Jun '17

30 Jun '17

Full_Name: Svetlana Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::c) Hi team, Could you please help us with the source file of 2.4.45 for Windows operating system from your website?

1 0

(ITS#8679) Update release download page
by quanah＠openldap.org 23 Jun '17

23 Jun '17

Full_Name: Quanah Gibson-Mount Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Download page needs updating to: a) Have links to the checksums for the release tarballs b) Have an encrypted download link option

1 0

(ITS#8678) Slow deletes of large indexed attrributes
by hyc＠openldap.org 22 Jun '17

22 Jun '17

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.31) Submitted by: hyc Related to ITS#7329 Recalculating the index values can be quite expensive when deleting a value from an attribute with many values. For 2.5 we should fix this by storing reference counts with each index slot.

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 22 Jun '17

22 Jun '17

--On Thursday, April 09, 2015 5:42 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.25.188.166) > > > When one has an MMR setup using delta-syncrepl, and the masters get into a > situation where one is out of sync, or adding a new MMR node to an > existing cluster, things will be broken until the new/reloaded node has a > write op that goes to the accesslog DB. In an existing cluster, where a > node is being reloaded, it causes all nodes to go into an endless looping > fallback sync until that write occurs. One possible fix for this, would be to refuse to delete the final entry in the accesslog during the purge phase. That way, the accesslog would never be empty. I'm not sure how difficult this would be to implement, code wise. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by michael＠stroeder.com 21 Jun '17

21 Jun '17

hyc(a)symas.com wrote: >> When using back-sock (database sock) and the external sock listener returns >> CONTINUE then slapd seg faults. >> >> Yes, returning CONTINUE is only allowed when using back-sock as overlay. >> But slapd should not seg fault and rather return as LDAP result: > > No. This is a configuration error and it's appropriate to halt the server and > force it to be fixed. Even if I follow your argument this message does not look like the server was deliberately halted: slapd: result.c:83: sock_read_and_send_results: Assertion `si->si_ops != 0' failed. ./start-slapd.sh: line 21: 30179 Aborted (core dumped) ${OPENLDAP_EXEC} -d stats,shell -h "ldap://0.0.0.0:9876 ${LDAPI_URI}" -n slapd-sock-test -f slapd.conf Also the args and PID files are not cleaned up. I guess database environment(s) of other backend(s) is/are also not closed in a controlled manner. So at least it should properly log a message and shutdown cleanly. Ciao, Michael.

1 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
by hyc＠symas.com 21 Jun '17

21 Jun '17

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.45 > OS: Linux > URL: > Submission from: (NULL) (213.240.182.98) > > > When using back-sock (database sock) and the external sock listener returns > CONTINUE then slapd seg faults. > > Yes, returning CONTINUE is only allowed when using back-sock as overlay. > But slapd should not seg fault and rather return as LDAP result: > > result: 80 Other (e.g., implementation specific) error > text: CONTINUE not allowed for back-sock No. This is a configuration error and it's appropriate to halt the server and force it to be fixed. -- -- 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#8677) back-sock segfaults on CONTINUE (database sock)
by michael＠stroeder.com 21 Jun '17

21 Jun '17

Full_Name: Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (213.240.182.98) When using back-sock (database sock) and the external sock listener returns CONTINUE then slapd seg faults. Yes, returning CONTINUE is only allowed when using back-sock as overlay. But slapd should not seg fault and rather return as LDAP result: result: 80 Other (e.g., implementation specific) error text: CONTINUE not allowed for back-sock

1 0

Re: (ITS#8676) openldap source uses implicit functoin declarations
by h.b.furuseth＠usit.uio.no 20 Jun '17

20 Jun '17

On 19. juni 2017 23:19, slyfox(a)gentoo.org wrote: > Why those are problems? implicit function declarations mean the > function type will be defaulted to int(int, int). > For functions like > int slap_sasl_cbinding( Connection *conn, struct berval *cbv ); > it might cause pointer-to-int truncation on 64-bit platforms. No, implicit declarations are defaulted to int(), and function call args are not converted other than integer promotions. So it's not a problem when the function are called with args of the correct types. But yeah, it won't hurt to clean up. -- Hallvard

1 0

(ITS#8676) openldap source uses implicit functoin declarations
by slyfox＠gentoo.org 19 Jun '17

19 Jun '17

Full_Name: Sergei Trofimovich Version: 2.4.44 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.154.9.158) When openldap package is being built in Gentoo GCC C compiler highlights a few problems of implicit function declaration usage as [1]. I've hacked up patches against current master: [2] Why those are problems? implicit function declarations mean the function type will be defaulted to int(int, int). For functions like int slap_sasl_cbinding( Connection *conn, struct berval *cbv ); it might cause pointer-to-int truncation on 64-bit platforms. Simplest way to reproduce the failure is to switch warning into failure as: ./configure CFLAGS="-Werror=implicit-function-declaration" make Many projects enable -Werror=implicit-function-declaration by default to catch that type of failure at development time. Thank you! [1]: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_i s_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you m ean pthread_setcanceltype? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_i s_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you m ean pthread_setcanceltype? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-ldap/bind.c:722:2: warning: implicit declaration of function slap_client_keepalive; did you me an slap_client_connect? [-Wimplicit-function-declaration] * /tmp/portage-tmpdir/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-meta/conn.c:424:2: warning: implicit declaration of function slap_client_keepalive; did you me an slap_client_connect? [-Wimplicit-function-declaration] * cloak.c:246:4: warning: implicit declaration of function attr_clean; did you mean entry_clean? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.OpenLDAP.org/ [2]: http://dev.gentoo.org/~slyfox/patches/openldap/0001-tls2.c-fix-implicit-lda… http://dev.gentoo.org/~slyfox/patches/openldap/0002-thr_posix.c-fix-implici… http://dev.gentoo.org/~slyfox/patches/openldap/0003-servers-slapd-config.c-… http://dev.gentoo.org/~slyfox/patches/openldap/0004-servers-slapd-connectio…

1 0

Re: (ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by acrow＠integrafin.co.uk 19 Jun '17

19 Jun '17

On 06/06/17 16:42, quanah(a)symas.com wrote: > --On Monday, June 05, 2017 6:08 PM +0000 acrow(a)integrafin.co.uk wrote: > >> Full_Name: Alex Crow >> Version: 2.4.40-13.el7 >> OS: Centos 7.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (95.172.237.70) >> >> >> I'm using OpenLDAP with the caching overlay as a proxy to AD, mostly for >> use with Postfix and Dovecot. >> >> I have been experiencing a strange issue whereby, when a user is moved to >> a different OU in AD, the caching server initially returns only the >> original OU until the cache entry expires. However, after this time, it >> returns both the entry in the original OU and the entry in the new OU. >> This does not seem to change even after the next expiry time has elapsed. >> I can only seem to clear out the "old" result by wiping the cache's >> database. > Hi Alex, > > The first thing to do would be to upgrade to OpenLDAP 2.4.44 or 2.4.45 and > confirm you can reproduce the issue in a current release. If you can, then > you need to provide a full backtrace, where debug symbols are enabled (the > "-g" flag for CFLAGS for gcc), and the slapd binary is not stripped (or if > using packaged RPMs, the debuginfo etc bits are installed). > > You can grab pre-compiled packages for OpenLDAP 2.4.44 from the LTB project > at <http://ltb-project.org/wiki/download#openldap>. I expect they'll have > 2.4.45 packages available soon as well. > > Thanks, > Quanah > Hi Quanah, I've installed a new VM with the current LTB release and the crashes don't seem to be happening. However, we're still seeing problems with the cache overlay not working as expected. We had a user account moved between OUs this morning shortly after 9am, and now at after 2pm the cache is still returning both the entry from the old OU and the new one (where postfix can only deal with one result in this case). Given my configuration I'd expect the cache to at least return the correct result after an hour at the most - or have I made a mistake? pcacheAttrset 0 mail x-mailHost x-mailStore unixHomeDirectory displayName pcacheTemplate (sn=) 0 3600 0 0 1800 pcacheTemplate (cn=) 0 3600 0 0 1800 pcacheTemplate (displayName=) 0 3600 0 0 1800 pcacheTemplate (mail=) 0 3600 0 0 1800 pcacheTemplate (&(objectClass=)(mail=)) 0 3600 0 0 1800 pcacheTemplate (&(objectClass=)(mail=*)) 0 3600 0 0 1800 Postfix is set up as below: ldaptransport_server_host = ldap://ldapcache2 ldap://ldapcache ldaptransport_timeout = 2 ldaptransport_search_base = OU=foo,DC=bar,DC=baz,DC=net ldaptransport_query_filter = (mail=%s) ldaptransport_result_attribute = x-mailHost ldaptransport_result_filter = relay:%s ldaptransport_expansion_limit = 1 Best regards Alex > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. This email is not intended to, nor should it be taken to, constitute advice. The information provided is correct to our knowledge & belief and must not be used as a substitute for obtaining tax, regulatory, investment, legal or any other appropriate advice. "Transact" is operated by Integrated Financial Arrangements Ltd. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856).

1 0

Re: (ITS#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by kurt＠boolean.net 19 Jun '17

19 Jun '17

it's standard conformance issue.... The spec says that upon StartTLS 'success', both TLS communications is = established on the octet following the Start TLS response (and the = request)... and that once one starts TLS communications, one can never = go back to LDAP without TLS. So if there's a TLS failure (whether as = part of TLS nego or later), LDAP communications cannot be continued = (without TLS). Only ignoring LDAP errors (rc > 0) ensures that if TLS negotiation = fails, we don't attempt to send LDAP operations without TLS. -- Kurt=

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by wferi＠niif.hu 19 Jun '17

19 Jun '17

I guess e338789d is supposed to fix this, and it's present in 2.4.40, but still I'm affected on that version: olcUniqueURI: ldap:///o=niifi,o=niif,c=hu?gidNumber?sub?objectClass=posixGroup rejects setting the gidNumber of a posixAccount to that of an existing posixGroup. The usual workaround of using more specific base DNs doesn't work well for me, because there are multiple branches containing groups. Specifying multiple URIs on the above light might work (man slapd-unique doesn't tell precisely), but requires extra maintenance. -- Feri

1 0

Re: (ITS#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by hyc＠symas.com 16 Jun '17

16 Jun '17

kurt(a)openldap.org wrote: > Full_Name: Kurt Zeilenga > Version: most every > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:f052:8000:7cca:294:b2d:2652) > > > The client tools were designed to support optimistic encryption (-Z)... in > cases where the server says "yes, let's start TLS...", TLS negotiations must be > entered into and, if they fail, no further LDAP traffic should be allowed on the > stream. Upon TLS alert, the session should no longer usable. Further attempts > to send any PDU should fail. I guess this was never stated clearly. "-ZZ" meant require TLS, drop the session if TLS fails. "-Z" meant proceed if TLS fails. No one ever specified exactly what types of failures were intended in either situation. > > But one could argue that the bug is simply the LDAP application software > ignoring the local (non-LDAP) errors coming from ldap_start_tls_s(). In this > case, the following trivial patch would address the issue. > > diff --git a/clients/tools/common.c b/clients/tools/common.c > index 7f758cb..089dd9b 100644 > --- a/clients/tools/common.c > +++ b/clients/tools/common.c > @@ -1367,7 +1367,7 @@ dnssrv_free:; > ldap_get_option( ld, > LDAP_OPT_DIAGNOSTIC_MESSAGE, (void*)&msg); > tool_perror( "ldap_start_tls", rc, NULL, NULL, > msg, NULL ); > ldap_memfree(msg); > - if ( use_tls > 1 ) { > + if ( use_tls > 1 || rc < 0) { > tool_exit( ld, EXIT_FAILURE ); > } > } > > However, it might be better to do something at a lower level to ensure that all > subsequent attempts to send LDAP PDUs over the wire after a TLS Alert fail. > > I hereby place the above patch into the public domain. > > -- -- 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#8675) tools continuing after ldap_start_tls_ returns non-LDAP error
by kurt＠openldap.org 16 Jun '17

16 Jun '17

Full_Name: Kurt Zeilenga Version: most every OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:f052:8000:7cca:294:b2d:2652) The client tools were designed to support optimistic encryption (-Z)... in cases where the server says "yes, let's start TLS...", TLS negotiations must be entered into and, if they fail, no further LDAP traffic should be allowed on the stream. Upon TLS alert, the session should no longer usable. Further attempts to send any PDU should fail. But one could argue that the bug is simply the LDAP application software ignoring the local (non-LDAP) errors coming from ldap_start_tls_s(). In this case, the following trivial patch would address the issue. diff --git a/clients/tools/common.c b/clients/tools/common.c index 7f758cb..089dd9b 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1367,7 +1367,7 @@ dnssrv_free:; ldap_get_option( ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, (void*)&msg); tool_perror( "ldap_start_tls", rc, NULL, NULL, msg, NULL ); ldap_memfree(msg); - if ( use_tls > 1 ) { + if ( use_tls > 1 || rc < 0) { tool_exit( ld, EXIT_FAILURE ); } } However, it might be better to do something at a lower level to ensure that all subsequent attempts to send LDAP PDUs over the wire after a TLS Alert fail. I hereby place the above patch into the public domain.

1 0

(ITS#8674) Leak in ldap_create_assertion_control
by matt.johnson＠hpe.com 15 Jun '17

15 Jun '17

Full_Name: Matt Johnson Version: 2.4.40 OS: RedHat 7.2 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.86) The LDAPClient::modify logic has a leak within the ldap_create_assertion_control method. The leaky code occurs when the existing ld_errno is anything but 0 when the method is invoked. Not only that, but your assertion returned is NULL. The workaround is to call the following before calling ldap_create_assertion_control. int lvErrno = 0; ldap_set_option(myLDAPPtr, LDAP_OPT_RESULT_CODE, &lvErrno);

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by remy.dernat＠univ-montp2.fr 12 Jun '17

12 Jun '17

Hi Ryan, Quanah, Le 11/06/2017 à 03:57, Ryan Tandy a écrit : > On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr > wrote: >> I am able to reproduce the bug quite easily. > > I'm afraid I have not been able to. I followed the steps you posted > (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 > and syncrepl seems to work fine. > > https://bugs.debian.org/798964 seems quite similar. R�my, do you think > this problem started for you right after you upgraded to +deb8u3? Indeed, I am afraid that this upgrade causes this issue, or maybe rather the previous one. `2.4.40+dfsg-1+deb8u2` were upgraded on my system in February and syncrepl does not work from this moment. Concerning tests from the latest source, I am not able to reproduce this bug as I get a weird error, with some stuff remaining from my previous install: ``` LDAP vendor version mismatch: library 20440, header 20445 ``` Google leads me to this topics : https://bbs.archlinux.org/viewtopic.php?id=56872 http://www.openldap.org/lists/openldap-software/200307/msg00399.html Although I removed every previous packages. Using ldd : ``` ldd `which ldapadd` linux-vdso.so.1 (0x00007ffe19765000) libldap-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap-2.4.so.2 (0x00007fef25b0d000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fef258fe000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fef256e1000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fef254aa000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fef25293000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef24ee7000) libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x00007fef24bc7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fef249aa000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fef247a5000) /lib64/ld-linux-x86-64.so.2 (0x000055776c6be000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fef2458a000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fef24344000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fef2412f000) libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007fef23efd000) libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2 (0x00007fef23cce000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fef23a4a000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fef23842000) ``` with strace : http://paste.debian.net/971168/ And no result with: ``` for file in `ldd /usr/local/bin/ldapadd |awk '{print $3}'`; do echo $file && objdump -T $file |grep 2044; done ``` (and nothing in /var/log/slapd.log) I should try to install it from a fresh install, it would be easier. Anyway, as you said, if installing it from a fresh install did not gave you this bug, I think you can close it... In the meantime, I am working with two other servers for production. As it works for me now (with hdb), I think I will remove the 2 others. This bug already took me too many time. Best regards, Rémy -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by ryan＠nardis.ca 11 Jun '17

11 Jun '17

On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr wrote: >I am able to reproduce the bug quite easily. I'm afraid I have not been able to. I followed the steps you posted (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 and syncrepl seems to work fine. https://bugs.debian.org/798964 seems quite similar. Rémy, do you think this problem started for you right after you upgraded to +deb8u3?

1 0

Re: (ITS#8664) lmdb fragmentation leads to DDoS for consumers
by quanah＠symas.com 09 Jun '17

09 Jun '17

--On Thursday, June 01, 2017 12:22 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) Going to close this out, as the problem statement & other bits is incorrect. I will file a new ITS with a better summary of the issues. Looking forward to a different bug tracker that allows modification of the bug summary, etc. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8673) Need duration logging for sync ops
by quanah＠openldap.org 08 Jun '17

08 Jun '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) We log the duration of an operation at stats level which allows being able to see how long a write OP took on a master. However we do not have any duration logging at the sync log level and therefore cannot determine how long a write op takes on a replica for the same modification. This is problematic when attempting to debug issues related to replication.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs