- openldap-bugs - openldap.org

[Issue 9940] New: slapadd segfault with -w on a subordinate database
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9940 Issue ID: 9940 Summary: slapadd segfault with -w on a subordinate database Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dhawes(a)gmail.com Target Milestone: --- I've noticed sporadic segfaults when using slapadd with -w and an LDIF that contains entries on a subordinate database. Removing -w prevents the segfault. I finally had some time to look at this, and the results are odder than I expected. gdb bt: ===== Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520) at dn.c:1192 1192 if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) { (gdb) bt #0 0x000055c2096c1ffd in dnIsSuffix (dn=0x55c20b82c7b8, suffix=0x55c20b749520) at dn.c:1192 #1 0x000055c20974262e in glue_back_select (be=0x7fff683fc5a0, dn=0x55c20b82c7b8) at backglue.c:77 #2 0x000055c209745473 in glue_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backglue.c:927 #3 0x000055c20974824d in overlay_entry_release_ov (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0, on=0x55c20b78d870) at backover.c:439 #4 0x000055c20974841f in over_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backover.c:483 #5 0x000055c2096b5f94 in be_entry_release_rw (op=0x7fff683fc840, e=0x55c20b82c7a0, rw=0) at backend.c:958 #6 0x000055c209750a3d in slap_tool_update_ctxcsn (progname=0x55c209813b08 "slapadd", sid=18446744073709551615, bvtext=0x7fff683fca20) at slapcommon.c:1015 #7 0x000055c20974e108 in slapadd (argc=11, argv=0x7fff683fce68) at slapadd.c:502 #8 0x000055c209672e56 in main (argc=11, argv=0x7fff683fce68) at main.c:723 (gdb) print *dn $1 = {bv_len = 94291905136528, bv_val = 0x0} ===== dn->bv_val is NULL in this case. This dumb patch prevents the segfault, but does not fix the root issue: ===== --- openldap-2.5.13/servers/slapd/dn.c 2022-07-14 13:09:57.000000000 -0400 +++ openldap-2.5.13-mod/servers/slapd/dn.c 2022-10-25 21:14:13.068933734 -0400 @@ -1188,6 +1188,11 @@ return 0; } + /* dn is null */ + if (dn->bv_val == NULL) { + return 0; + } + /* no rdn separator or escaped rdn separator */ if ( d > 1 && !DN_SEPARATOR( dn->bv_val[ d - 1 ] ) ) { return 0; ===== When I started creating a minimal config for this issue, things got stranger. First, the config: ===== include /usr/local/openldap-2.5.13/etc/openldap/schema/core.schema database mdb suffix "ou=Subordinate,dc=vt,dc=edu" subordinate rootdn "cn=Manager,dc=vt,dc=edu" directory /usr/local/openldap-2.5.13/var/openldap-data/subordinate maxsize 17179869184 index objectClass eq index uid,entryCSN,entryUUID eq database mdb suffix "dc=vt,dc=edu" rootdn "cn=Manager,dc=vt,dc=edu" directory /usr/local/openldap-2.5.13/var/openldap-data/mdb maxsize 17179869184 index objectClass eq index uid,entryCSN,entryUUID eq ===== The LDIF: ===== dn: dc=vt,dc=edu objectClass: dcObject objectClass: organization o: Virginia Tech dc: vt structuralObjectClass: organization entryUUID: e906e392-731f-1034-98c4-c3e119ef52ff creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409161915Z entryCSN: 20150409161915.467619Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409161915Z contextCSN: 20221025003300.622285Z#000000#000#000000 dn: ou=Subordinate,dc=vt,dc=edu objectClass: dcObject objectClass: organizationalUnit dc: vt ou: subordinate structuralObjectClass: organizationalUnit entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5 creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409162852Z entryCSN: 20150409162852.039034Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409162852Z ===== Unfortunately, that config and LDIF did not result in a segfault, but I noticed that in my LDIFs that do, there is data after the subordinate entry, but that data is commented out. Adding a small comment did not affect things, but adding a large comment at the end of the LDIF did (4113 characters): ===== #000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a ===== If you remove the 'a' from the end of that comment, there is no segfault. Note that this is sporadic, so I'm running in a loop to detect it: for i in {1..10}; do rm /usr/local/openldap-2.5.13/var/openldap-data/*/*.mdb; slapadd -q -w -b dc=vt,dc=edu -l ./minimal.ldif; done; This also seems to be the case with entries after the subordinate entry that have long attribute values (1027 characters, only tested with dc): ===== dn: ou=1,dc=vt,dc=edu objectClass: dcObject objectClass: organizationalUnit dc: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a ou: 1 structuralObjectClass: organizationalUnit entryUUID: 40b0b450-7321-1034-9e54-3f41091a54c5 creatorsName: cn=Manager,dc=vt,dc=edu createTimestamp: 20150409162852Z entryCSN: 20150409162852.039034Z#000000#000#000000 modifiersName: cn=Manager,dc=vt,dc=edu modifyTimestamp: 20150409162852Z ===== Remove the 'a' from the end of dc, and no segfault. I hope that's enough information to recreate this issue. I'm still looking at it, but I haven't found the root cause yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9937] New: slapd buffer overflow in put_simple_filter()
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9937 Issue ID: 9937 Summary: slapd buffer overflow in put_simple_filter() Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- Running this results in heap buffer overflow. ./servers/slapd/slapd -T c -a= SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/juhee/project/foxfuzz/programs/network/openldap-test/servers/slapd/slap d+0x726702) Shadow bytes around the buggy address: 0x0c047fffcb10: fa fa 00 07 fa fa 00 00 fa fa 03 fa fa fa 00 05 0x0c047fffcb20: fa fa 02 fa fa fa 02 fa fa fa 03 fa fa fa 07 fa 0x0c047fffcb30: fa fa 02 fa fa fa 03 fa fa fa 06 fa fa fa 00 03 0x0c047fffcb40: fa fa 00 06 fa fa 00 02 fa fa 00 01 fa fa 00 04 0x0c047fffcb50: fa fa 00 00 fa fa 00 fa fa fa 00 02 fa fa 02 fa =>0x0c047fffcb60: fa[fa]02 fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcbb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2262407==ABORTING Breakpoint 1, 0x00005555556ca320 in __asan_report_load1 () gdb-peda$ bt #0 0x00005555556ca320 in __asan_report_load1 () #1 0x0000555555c7a703 in put_simple_filter () #2 0x0000555555c7a309 in ldap_pvt_put_filter () #3 0x000055555588ca2b in str2filter_x () #4 0x000055555588ced4 in str2filter () #5 0x0000555555a31b61 in slap_tool_init () #6 0x0000555555a2e34d in slapcat () #7 0x0000555555708e1f in main () #8 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x4, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #9 0x000055555561011e in _start () -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9935] New: buffer overflow in UTF8StringValidate
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9935 Issue ID: 9935 Summary: buffer overflow in UTF8StringValidate Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- I get a heap buffer overflow running this on the latest openldap on git. Built with CFLAGS="-fsanitize=address" using clang 15. ./servers/slapd/slapd $(python2 -c 'print("-Td \x4c\x3d\xc2\x8c\xf0\xf0")') SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/juhee/project/foxfuzz/programs/network/openldap-ori/servers/slapd/slapd +0x3961ac) Shadow bytes around the buggy address: 0x0c047fffcb00: fa fa 00 06 fa fa 00 00 fa fa 00 07 fa fa 00 00 0x0c047fffcb10: fa fa 00 07 fa fa 00 00 fa fa 03 fa fa fa 00 05 0x0c047fffcb20: fa fa 02 fa fa fa 02 fa fa fa 03 fa fa fa 07 fa 0x0c047fffcb30: fa fa 02 fa fa fa 03 fa fa fa 06 fa fa fa 00 03 0x0c047fffcb40: fa fa 00 06 fa fa 00 02 fa fa 00 01 fa fa 00 04 =>0x0c047fffcb50: fa fa 00 00 fa fa 00 fa fa fa 00 02 fa fa[05]fa 0x0c047fffcb60: fa fa 00 00 fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffcba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2202218==ABORTING Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffc4d6, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c6461 in __asan::ReportGenericError (pc=<optimized out>, bp=0x7fffffffd140, sp=0x7fffffffd138, addr=0x602000025af5, is_write=is_write@entry=0x0, access_size=0x1, fatal=0x1, exp=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c99d6 in __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=0x7fffffffd140, sp=sp@entry=0x7fffffffd138, addr=<optimized out>, is_write=is_write@entry=0x0, access_size=access_size@entry=0x1, exp=<optimized out>, fatal=0x1) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang.h:74 #7 0x00005555556ca34c in __asan::__asan_report_load1 (addr=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:118 #8 0x00005555558ea1ad in UTF8StringValidate () #9 0x000055555581e5a7 in LDAPRDN_rewrite () #10 0x000055555581d059 in LDAPDN_rewrite () #11 0x0000555555820f7f in dnPrettyNormal () #12 0x0000555555a37d1d in slapdn () #13 0x000055555570901f in main () #14 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x3, argv=0x7fffffffdfd8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfc8) at ../csu/libc-start.c:308 #15 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9930] New: test050 deadlock on BSD OSes
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9930 Issue ID: 9930 Summary: test050 deadlock on BSD OSes Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Initially reported to me directly as an issue with NetBSD 9.1, I was able to reproduce this with FreeBSD 13.1 as well. Investigation ongoing. Running test050 in a loop eventually results in a deadlock in one of the 4 slapd provider processes. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9898] New: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9898 Issue ID: 9898 Summary: slapd-addel.c contains invalid struct initialization which does not compile on HP-UX aCC Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- My compiler (cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]) gives me: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include -I/opt/ports/include -c -o slapd-addel.o slapd-addel.c "slapd-addel.c", line 68: error #2029: expected an expression LDIFRecord record = {}; ^ "slapd-addel.c", line 70: error #2029: expected an expression struct berval bv = {}; ^ This is invalid C code, it can be easily solved by using "{0}" and the code does compile. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9892] New: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9892 Issue ID: 9892 Summary: LDAP_TXN_SPECIFY assumes cleanup responsibility for writes but never performs it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When TXN extop is accepted and the client sends some write ops, the cleanup path is skipped within do_modify/do_add/... however the data is never actually freed when the transaction is being settled (regardless of whether it was committed successfully or aborted). Confirmed to happen with do_modify by tests/scripts/lloadd/test007-coherence, for others it's my assumption based on reading the code. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9880] New: reqStart filter with trailing zeros is truncated, which breaks certain searches
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9880 Issue ID: 9880 Summary: reqStart filter with trailing zeros is truncated, which breaks certain searches Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- Note: ITS#9358 seems to address this very issue, but it doesn't seem to help this particular case. Certain range searches with reqStart on the changelog don't work as expected. For example: (!(reqStart<=20220707123456.000000Z)) The idea here is to grab all entries strictly greater than the timestamp. But slapd truncates zeros in this filter, rewriting it to: (!(reqStart<=20220707123456Z)) As a result, the reqStart=20220707123456.000000Z entry is the first match since it is greater than 20220707123456Z, which is not the desired behavior. I was able to reproduce this issue on 2.5.12 as follows: 1) Start the test043-delta-syncrepl test, let it run almost to the end so that it makes many changes, and then hit ^Z to suspend the script. I waited until one of the last occurrences of "Waiting 7 seconds for syncrepl to receive changes". 2) pkill -CONT -f slapd to restart slapd (but not the test script) 3) ldapsearch -x -h localhost:9011 -b cn=log objectclass=top | grep '^dn:.*.000000Z' Look for a change with all trailing zeros. It's not as rare as one might think, I saw at least one trailing-zeros change in two consecutive runs of the test script. I suppose you could also just create an entry with all trailing zeros in the accesslog :-) 4) Run a range search to only return changes after that change (I used -z 1 and -s one so that it would only give me one result): ldapsearch -x -z 1 -h localhost:9011 -b cn=log -s one '(!(reqStart<=20220708012121.000000Z))' If you see the same entry, then the problem is present. 5) Even if you can't have an accesslog entry with all trailing zeros, you can still do the above search verbatim and look at the slapd log file testrun/slapd.1.log: 62c7873f.145b4396 0x7fabf14c9700 conn=1011 op=1 SRCH base="cn=log" scope=1 deref =0 filter="(!(reqStart<=20220708012121Z))" The filter being rewritten in the server log seems to indicate that trailing zeros are being truncated somewhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9966] New: slapd crashes in pcache consistency_check()
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9966 Issue ID: 9966 Summary: slapd crashes in pcache consistency_check() Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- The pcache overlay (when run with multiple templates) crashes in the consistency checker. Cause appears to be that "expires" is not reset for the next iteration of the template loop. I can provide more details if necessary. Server does not crash with this in place: diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 423c19641e72..7b9e2061f927 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -3628,6 +3628,8 @@ consistency_check( if ( rem ) free_query(query); } + expires = NULL; + /* handle refreshes that we skipped earlier */ if ( templ->ttr ) { ldap_pvt_thread_rdwr_rlock(&templ->t_rwlock); valgrind says: ==217138== Thread 13: ==217138== Invalid read of size 8 ==217138== at 0x63949EE: consistency_check (pcache.c:3604) ==217138== by 0x48A5DB9: ldap_int_thread_pool_wrapper (tpool.c:1053) ==217138== by 0x5016801: start_thread (in /usr/lib64/libc.so.6) ==217138== by 0x4FB6313: clone (in /usr/lib64/libc.so.6) ==217138== Address 0x6d14c60 is 160 bytes inside a block of size 240 free'd ==217138== at 0x48470E4: free (vg_replace_malloc.c:872) ==217138== by 0x63949DE: UnknownInlinedFun (pcache.c:1548) ==217138== by 0x63949DE: consistency_check (pcache.c:3628) ==217138== by 0x48A5DB9: ldap_int_thread_pool_wrapper (tpool.c:1053) ==217138== by 0x5016801: start_thread (in /usr/lib64/libc.so.6) ==217138== by 0x4FB6313: clone (in /usr/lib64/libc.so.6) ==217138== Block was alloc'd at ==217138== at 0x484486F: malloc (vg_replace_malloc.c:381) ==217138== by 0x48C8804: ber_memalloc_x (memory.c:228) ==217138== by 0x4598C2: ch_malloc (in /usr/local/libexec/slapd) ==217138== by 0x6391276: add_query (pcache.c:1562) ==217138== by 0x639ADEF: pcache_op_cleanup (pcache.c:2376) ==217138== by 0x52498D: ??? (in /usr/local/libexec/slapd) ==217138== by 0x452C32: ??? (in /usr/local/libexec/slapd) ==217138== by 0x4536BC: slap_send_ldap_result (in /usr/local/libexec/slapd) ==217138== by 0x4CF9EA: ldap_back_search (in /usr/local/libexec/slapd) ==217138== by 0x4BD022: overlay_op_walk (in /usr/local/libexec/slapd) ==217138== by 0x4BD1A0: ??? (in /usr/local/libexec/slapd) ==217138== by 0x4415D8: fe_op_search (in /usr/local/libexec/slapd) ==217138== Happy Holidays! -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9960] New: Problem with accesslog overlay along with dynlist overlay
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9960 Issue ID: 9960 Summary: Problem with accesslog overlay along with dynlist overlay Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: carsten.jaeckel(a)tu-dortmund.de Target Milestone: --- As long as only the accesslog overlay is used the logging works as expected. Successfully logged search access: ldapsearch -H ldaps://ldap.example.com:636 -D cn=manager,dc=example,dc=com -W -b dc=users,dc=example,dc=com cn=user1 mail Result of ldapsearch -H ldaps://ldap.example.com:636 -D cn=log -W -b cn=log objectclass=*: ###################################### ... # 20221212145029.000000Z, log dn: reqStart=20221212145029.000000Z,cn=log objectClass: auditBind reqStart: 20221212145029.000000Z reqEnd: 20221212145029.000001Z reqType: bind reqSession: 1022 reqAuthzID: reqDN: cn=manager,dc=example,dc=com reqResult: 0 reqVersion: 3 reqMethod: SIMPLE # 20221212145029.000002Z, log dn: reqStart=20221212145029.000002Z,cn=log objectClass: auditSearch reqStart: 20221212145029.000002Z reqEnd: 20221212145029.000003Z reqType: search reqSession: 1022 reqAuthzID: manager,dc=example,dc=com reqDN: dc=users,dc=example,dc=com reqResult: 0 reqScope: sub reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (cn=user1) reqAttr: mail reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: -1 # 20221212145029.000004Z, log dn: reqStart=20221212145029.000004Z,cn=log objectClass: auditObject reqStart: 20221212145029.000004Z reqEnd: 20221212145029.000005Z reqType: unbind reqSession: 1022 reqAuthzID: manager,dc=example,dc=com ###################################### After adding overlay dynlist the information in the accesslog database after the same search operation ldapsearch -H ldaps://ldap.example.com:636 -D cn=manager,dc=example,dc=com -W -b dc=users,dc=example,dc=com cn=user1 mail is as follows: ###################################### ... # 20221212144859.000000Z, log dn: reqStart=20221212144859.000000Z,cn=log objectClass: auditBind reqStart: 20221212144859.000000Z reqEnd: 20221212144859.000001Z reqType: bind reqSession: 1019 reqAuthzID: reqDN: manager,dc=example,dc=com reqResult: 0 reqVersion: 3 reqMethod: SIMPLE # 20221212144859.000002Z, log dn: reqStart=20221212144859.000002Z,cn=log objectClass: auditSearch reqStart: 20221212144859.000002Z reqEnd: 20221212144859.000003Z reqType: search reqSession: 1019 reqAuthzID: manager,dc=example,dc=com reqDN: dc=users,dc=example,dc=com reqResult: 0 reqScope: sub reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (objectClass=groupOfURLs) reqAttr: memberURL reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: -1 # 20221212144859.000005Z, log dn: reqStart=20221212144859.000005Z,cn=log objectClass: auditObject reqStart: 20221212144859.000005Z reqEnd: 20221212144859.000006Z reqType: unbind reqSession: 1019 reqAuthzID: manager,dc=example,dc=com ###################################### Configuration: ###################################### dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb ... olcSuffix: dc=example,dc=com olcSyncUseSubentry: FALSE dn: olcOverlay={0}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {0}refint olcRefintAttribute: member olcRefintAttribute: memberOf olcRefintNothing: cn=tgroup,dc=groups,dc=example,dc=com dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyHashCleartext: TRUE dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcDynListConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames dn: olcOverlay={3}lastbind,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcLastBindConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {3}lastbind olcLastBindPrecision: 86400 dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcConfig objectClass: olcOverlayConfig objectClass: top olcAccessLogDB: cn=log olcOverlay: {4}accesslog olcAccessLogOld: (objectClass=inetOrgPerson) olcAccessLogOldAttr: description olcAccessLogOps: all olcAccessLogPurge: 01:00 00:15 ###################################### -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9929] New: slapo-dynlist unnecessary search for dynamic lists
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9929 Issue ID: 9929 Summary: slapo-dynlist unnecessary search for dynamic lists Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- An extra initial search is performed by slapo-dynlist to make dynamic groups filterable. This search is not needed for dynamic lists, but is still occurring. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9924] New: Increased/RunAway memory usage slapo-deref
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9924 Issue ID: 9924 Summary: Increased/RunAway memory usage slapo-deref Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: erikdewaard(a)gmail.com Target Milestone: --- Created attachment 916 --> https://bugs.openldap.org/attachment.cgi?id=916&action=edit slapd.conf Increased/RunAway memory usage slapo-deref Running: 2.5.13 After enabling slapo-deref slapd memory usage increased and growing. I can reproduce this on every consumer with deref enabled. From: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 173229 ldap 20 0 26.6g 1.0g 941996 S 4.0 0.8 3674:19 slapd To: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2745810 ldap 20 0 141.5g 115.8g 468940 S 3.0 92.5 312:42.93 slapd How best to debug this? I should probably recompile to get all symbols for slapd available. #valgrind.sh valgrind --leak-check=full \ --show-leak-kinds=all \ --extra-debuginfo-path=/usr/lib/debug/usr/lib64/openldap \ --allow-mismatched-debuginfo=yes \ --track-origins=yes \ --error-limit=no \ --verbose \ --log-file=valgrind-out.txt \ /usr/sbin/slapd -F /etc/openldap/slapd.d -u ldap -h "ldap:/// ldaps:/// ldapi:///" #mleak.sh LD_PRELOAD=/tmp/mleak/mleak.so \ /usr/sbin/slapd -F /etc/openldap/slapd.d -u ldap -h "ldap:/// ldaps:/// ldapi:///" sent kill -2 #mleak_report.sh ./mdump /usr/sbin/slapd ml.* ./report.sh | more fncdump: Cant open linux-vdso.so.1 Memory leaks (14480 total): -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 9915] New: Changing slapo-unique to use serialize causes cn=config replication to fail
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9915 Issue ID: 9915 Summary: Changing slapo-unique to use serialize causes cn=config replication to fail Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- I updated my slapo-unique configuration from: olcUniqueURI: ldap:///?uid?sub? to olcUniqueURI: "serialize ldap:///?uid?sub?" and replication of the config database fails with the following error: syncrepl_null_callback: error code 0x50 syncrepl_entry: rid=001 be_modify olcOverlay={2}unique,olcDatabase={2}mdb,cn=config (80) syncrepl_entry: rid=001 be_modify failed (80) -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9897] New: ldapcompare return FALSE when dynlist in use
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9897 Issue ID: 9897 Summary: ldapcompare return FALSE when dynlist in use Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sdalu(a)sdalu.com Target Milestone: --- The server configuration enable dynlist with: overlay dynlist dynlist-attrset groupOfURLs memberURL member Entry is: dn: cn=Admins,ou=Services,ou=Members,dc=zog,dc=com member: uid=foo,ou=People,dc=zog,dc=com cn: Admins objectClass: groupOfNames The ldap compare will return false, was expected true ldapcompare -x cn=Admins,ou=Services,ou=Members,dc=zog,dc=com member:uid=foo,ou=People,dc=zog,dc=com Now if I comment the dynlist-attrset directive, I will get TRUE for the same ldapcompare request -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9984] New: Balancer listener thread exits when all listeners are suspended
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9984 Issue ID: 9984 Summary: Balancer listener thread exits when all listeners are suspended Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If lloadd runs out of file descriptors, the listeners are paused temporarily, however the event base is not configured to stick around if all of its tasks have finished. In case all of the listeners are paused, the event base exits and listener thread goes away. A patch is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9983] New: operation_unlink files the operation before it is fully unlinked
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9983 Issue ID: 9983 Summary: operation_unlink files the operation before it is fully unlinked Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In epoch based memory management, objects should only be submitted for reclaiming when no actors can reach them unless they've done that before the submission happened. This is broken in operation_unlink(): It calls try_release_ref() at the beginning where the operation is added to the to-reclaim list, only then it proceeds to unlink it from other objects. The following sequence is then possible: - current_epoch == 1 (no threads are alive in epoch == 0) - in thread 1 (epoch = 1), try_release_ref() marks the object to be reclaimed in current_epoch - thread 2 activates and current_epoch is incremented (current_epoch == 2) - thread 2 handles an Unbind for the operation's client and reaches client_reset() (epoch == 2) - thread 2 (client_reset) snapshots and clears client->c_ops (among other things, c->c_ops links to our object) - thread 1 finishes operation_unlink, deactivates and there are no more threads in epoch == 1 - thread 3 activates and current_epoch is incremented (current_epoch == 3), there are objects in epoch == 1, namely the object above which is now destroyed (freed) - thread 2 wakes up again and tries to call operation_abandon on the above object, this accesses memory freed epoch_append (and try_release_ref) should only be called when unlinking has finished. I'm testing a patch right now. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9947] New: Race in epoch.c
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9947 Issue ID: 9947 Summary: Race in epoch.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When epoch_leave() tests whether other threads might still be alive, it can test things in reverse order, testing too early to catch a thread to come in and too late to see a thread that just left. If those two saw each other, the clock would not advance and the data in refs might actually still be a reachable pointer. The tests in epoch_leave can actually be simplified leading to machine code not all compilers could figure out by themselves. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9925] New: Fix some compilation issues around usage of #if and #ifdef
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9925 Issue ID: 9925 Summary: Fix some compilation issues around usage of #if and #ifdef Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: connor.smith(a)hitachivantara.com Target Milestone: --- Created attachment 918 --> https://bugs.openldap.org/attachment.cgi?id=918&action=edit git format-patch I noticed a few issues while working with OpenLDAP that would lead to compiler warnings and the like in our particular build environment. They're quite minor, but it would still be good to have them patched upstream. In include/ac/socket.h: Use #elif defined(...) for HAVE_WINSOCK and MACOS. All other instances of these macros use #ifdef or similar. A compiler may warn about them not being defined. In libraries/liblber/sockbuf.c, (DOS && PCNFS) and (DOS && NCSA) were replaced with HAVE_PCNFS and HAVE_NCSA, respectively. It seems logical to do the same at the only remaining occurrence of DOS, PCNFS, and NCSA. For context on the latter: the actual warning was about #elif DOS, similar to #elif HAVE_WINSOCK and #elif MACOS, but looking into it it seemed to make sense to bring socket.h in line with sockbuf.c. In libraries/liblunicode/ucdata/ucgendat.c: Use #if HARDCODE_DATA consistently, replacing two instances of #ifdef. HARDCODE_DATA is always defined, and this way you can set HARDCODE_DATA to 0 and have it work, rather than it going down the wrong branch and failing in these two cases. An IPR notice, with this work having been done as part of my employment: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Hitachi Vantara. Hitachi Vantara has not assigned rights and/or interest in this work to any party. I, Connor Smith, am authorized by Hitachi Vantara, my employer, to release this work under the following terms. Hitachi Vantara hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Please let me know if there are any issues with the attached patch, or if there's anything else I need to do. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9904] New: A Potential NPD
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9904 Issue ID: 9904 Summary: A Potential NPD Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1157401338(a)qq.com Target Milestone: --- Created attachment 911 --> https://bugs.openldap.org/attachment.cgi?id=911&action=edit diagram of NPD Hi, I found a NPD bug in the project source code of ldap, and I have shown the execution sequence of the program that may have generated the bug on a diagram,which is added to the attachment The red text illustrates the steps that created the bug the red arrows represent the call relationships the file path can be seen in the blue framed section. additionally,at step 4 I do not expand more detail about why function ber_memalloc_x can return null(actually it can be seen as function malloc and the reason ber_memalloc_x return null is same with malloc),because there are many code snippet can be found in project source code that judge whether ber_memalloc_x return null and make further process if return value equal to null. I look forward to your reply and thank you very much for your patience! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9901] New: Fix non-standard printf arguments in liblbert and libldap
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9901 Issue ID: 9901 Summary: Fix non-standard printf arguments in liblbert and libldap Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Created attachment 910 --> https://bugs.openldap.org/attachment.cgi?id=910&action=edit Patch gainst source tarball As a followup to Bug 9898 and Bug 9899 I have played around with LLVM 13 and "-std=c17 -pedantic -Wall" it fails to compile several files. Find a patch attached which makes it standards compliant. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9899] New: "cyrus.c" uses non-portable GNU extension for void pointer arithmetics and fails on HP-UX aCC
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9899 Issue ID: 9899 Summary: "cyrus.c" uses non-portable GNU extension for void pointer arithmetics and fails on HP-UX aCC Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- On HP-UX with cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016] tells me libtool: compile: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include -I/opt/ports/include -DLDAP_LIBRARY -c cyrus.c -DPIC -o .libs/cyrus.o "cyrus.c", line 420: error #3143: arithmetic on pointer to void or function type memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len ); ^ 1 error detected in the compilation of "cyrus.c". gmake[2]: *** [Makefile:434: cyrus.lo] Error 1 void pointer arithmetics is not valid/undefined and just a GNU extension supported by GCC or clang. I was able to reproduce this on FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303): osipovmi@deblndw011x:~/var/Projekte/openldap-2.6.3/libraries/libldap $ cc -std=c17 -I../../include -I../../include -I/usr/local/include -DLDAP_LIBRARY -c cyrus.c -o cyrus.o -pedantic -Werror cyrus.c:420:18: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wpointer-arith] memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len ); ~~~~~~~ ^ 1 error generated. I am not a daily C hacker, but I guess cb_data needs to be typed to "unsigned char" just like data from sasl_channel_binding_t (https://github.com/cyrusimap/cyrus-sasl/blob/cb549ef71c5bb646fe583697ebdcab…). Or at least a malloc with an "unsigned char", save the pointer start address, copy the prefix, increment by prefix length, copy the channel binding value and then assign the pointer start address to the output struct. I will unset SASL_CHANNEL_BINDING for now since it is not required in your AD environment when SASL GSSAPI with minssf=1 is set. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9976] New: ldap_sasl_bind_s man page missing details on freeing the returned servercredp parameter
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9976 Issue ID: 9976 Summary: ldap_sasl_bind_s man page missing details on freeing the returned servercredp parameter Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: wmjchs(a)hotmail.com Target Milestone: --- Source code for ldap_sasl_bind_s shows that the parameter is to be freed via ber_bvfree when no longer used. (https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/…) However, the documentation (https://www.openldap.org/software/man.cgi?query=ldap_sasl_bind_s&apropos=0&…) makes no mention of this. The following sources also omitted this information: https://linux.die.net/man/3/ldap_sasl_bind_s https://www.ibm.com/docs/en/i/7.4?topic=ssw_ibm_i_74/apis/ldap_sasl_bind_s.… https://learn.microsoft.com/en-us/windows/win32/api/winldap/nf-winldap-ldap… While the following didn't: https://www.novell.com/documentation/developer/cldap/ldaplibc/data/a401rtp.… https://www.ibm.com/docs/en/zos/2.3.0?topic=routines-ldap-sasl-bind-ldap-sa… https://docs.oracle.com/cd/E19957-01/817-6707/functions.html#wp57022 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9957] New: slapo-dynlist manpage needs better description of dynlist-attrset
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9957 Issue ID: 9957 Summary: slapo-dynlist manpage needs better description of dynlist-attrset Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Each dynlist-attrset defines one of three distinct behaviours: - dynamic list (attributes are gathered from other entries) - dynamic group (DNs are gathered based on other entries) - static group (DNs are gathered based on DNs stored on entries) With the groups possibly being recursive, requiring traversal. Since the above do not mix, the documentation should be more explicit about how each one should look and behave. It should also be noted somewhere what happens (or not) when multiple dynlist-attrset stanzas would apply to the same entry. At that point, configuration code could also be made more strict to reject configurations that satisfy the apparent dynlist-attrset syntax but do not actually represent anything that fits just one of the above and is therefore nonsensical (with parts of it apparently ignored at runtime). With nonsensical configuration rejected, it would be possible to streamline internal dynlist structures and make critical parts of the overlay code more readable. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9941] New: back-asyncmeta(5) man page has incorrect information
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9941 Issue ID: 9941 Summary: back-asyncmeta(5) man page has incorrect information Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Currently the man page states that asyncmeta selects the connection queue with the least number of pending operations as the next connection, but that was dropped a while ago, and the connections queues are selected round-robin. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9985] New: slapd-modules/passwd/totp does not build .so file
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9985 Issue ID: 9985 Summary: slapd-modules/passwd/totp does not build .so file Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: bastian-bugopenldap21(a)t6l.de Target Milestone: --- I try to build the contrib module totp from openldap 2.6.3. The README states to run `make` in order to build the dynamic link-able .so file. It does not so on my test system (could be a flaw on the test system though). Many thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9917] New: Remove -h and -p from options[] in client tools
by openldap-its＠openldap.org 09 Feb '23

09 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9917 Issue ID: 9917 Summary: Remove -h and -p from options[] in client tools Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: daniels.thomas(a)pm.me Target Milestone: --- Created attachment 914 --> https://bugs.openldap.org/attachment.cgi?id=914&action=edit patch for this issue The options -h and -p got removed from client tools (https://bugs.openldap.org/show_bug.cgi?id=8618). However, they were still present in the options[] array in several client tools source files. So, if one of those tools got executed with -h or -p followed by a value, this lead to the error "unrecognized option -", without mentioning which option was problematic. Removing 'h' and 'p' from options[] fixes this. This patch does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs