openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs