openldap-bugs November 2025

openldap-bugs@openldap.org

1 participants
228 discussions

[Issue 5625] memberOf search ACLs
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

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

1 0

[Issue 5625] memberOf search ACLs
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

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

1 0

[Issue 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9731 Issue ID: 9731 Summary: startup messages still go to syslog when logfile-only is on Product: OpenLDAP Version: 2.6.0 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 setting logfile-only on, slapd still logs its startup message to syslog: Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021 05:12:17) $#012#011openldap This is useful information to have consolidated into the specified logfile. Note that: 617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting does make it to the logfile. However, it would be useful to have the build date and version in the specified logfile. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10407] New: unable to load TLS module
by openldap-its＠openldap.org 19 Nov '25

19 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10407 Issue ID: 10407 Summary: unable to load TLS module Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 953361205(a)qq.com Target Milestone: --- Created attachment 1094 --> https://bugs.openldap.org/attachment.cgi?id=1094&action=edit detail log The version of openssl is 3.0.2 in my server. I wanted to install openldap with TLS support. So I entered the command "./configure --with-tls=openssl" under the path of openldap project folder, then I got the following error: ... checking for hstrerror... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for gai_strerror... yes checking for inet_ntop... yes checking INET6_ADDRSTRLEN... yes checking struct sockaddr_storage... yes checking for sys/un.h... yes checking for openssl/ssl.h... yes checking for SSL_CTX_set_ciphersuites in -lssl... no configure: error: Could not locate TLS/SSL package --------------------------------------------------------------- I also attached the detail log. Please tell me how to deal with the problem. Looking forward to replying. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its＠openldap.org 12 Nov '25

12 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 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: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 33

[Issue 10405] New: freebsd package missing mdb module in openldap server 2.6.10
by openldap-its＠openldap.org 07 Nov '25

07 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10405 Issue ID: 10405 Summary: freebsd package missing mdb module in openldap server 2.6.10 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: enda(a)cronnolly.com Target Milestone: --- When installing openldap server on FreeBSD 14.3, the package: openldap26-server-2.6.10 Open source LDAP server implementation Has the following shared objects in the module folder: ls /usr/local/libexec/openldap/back_*.so /usr/local/libexec/openldap/back_asyncmeta.so /usr/local/libexec/openldap/back_null.so /usr/local/libexec/openldap/back_dnssrv.so /usr/local/libexec/openldap/back_passwd.so /usr/local/libexec/openldap/back_ldap.so /usr/local/libexec/openldap/back_sock.so /usr/local/libexec/openldap/back_meta.so slapd.conf references these modules: # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_mdb # moduleload back_ldap but back_mdb is missing from the installed modules. There appears to be no other way to install this module through the package system and the only way to run openldap server 2.6.10 is to build it from ports instead of using the broken package. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 05 Nov '25

05 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 7929b3ee by Arvid Requate at 2025-10-22T19:25:34+00:00 ITS#7901 slapschema: preserve errors in -c mode RE26: • 72a16079 by Arvid Requate at 2025-11-04T16:13:34+00:00 ITS#7901 slapschema: preserve errors in -c mode -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 05 Nov '25

05 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2025