openldap-bugs

openldap-bugs@openldap.org

1 participants
21566 discussions

[Issue 10648] New: More fixes to pcache
by openldap-its＠openldap.org 26 Oct '26

26 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10648 Issue ID: 10648 Summary: More fixes to pcache Product: OpenLDAP Version: 2.6.15 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1237 --> https://bugs.openldap.org/attachment.cgi?id=1237&action=edit Fixes for pcache.c Hello, I have some more fixes for the pcache overlay for issues we're seen. These are based on 2.6.15. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10643] New: DUPSORT page counts remain inflated after deleting a duplicate tree
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10643 Issue ID: 10643 Summary: DUPSORT page counts remain inflated after deleting a duplicate tree Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: ledvinap(a)gmail.com Target Milestone: --- b048b7e (ITS#9388) updates the parent’s page counts only when the duplicate child tree still contains entries. Whole-set deletion and deletion of the last value skip adjustment. Fix: subtract counts still in NODEDATA(leaf) after successful mdb_drop0(). AI discovery/fix; This report is fully authored by me. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10615] New: Stale reads with nested LMDB transactions on OpenBSD
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10615 Issue ID: 10615 Summary: Stale reads with nested LMDB transactions on OpenBSD Product: LMDB Version: unspecified Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: wiesche89(a)googlemail.com Target Milestone: --- On OpenBSD 7.9, LMDB reads can return stale data after writes through the file descriptor when using nested transactions Reproduced with heed 0.22.1 and lmdb-master-sys 0.2.6 Adding msync(..., MS_INVALIDATE) after data and metadata writes fixes it in my tests MDB_WRITEMAP also avoids it, but does not support nested write transactions Proposed fix: https://github.com/meilisearch/lmdb/pull/5 Backport: https://github.com/wiesche89/lmdb/commit/52b4d64d5ab39952a4105151fd3b454019… Reported here: https://github.com/meilisearch/heed/issues/383 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10642] New: unaligned MDB_db access in mdb_subdb_adjust()
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10642 Issue ID: 10642 Summary: unaligned MDB_db access in mdb_subdb_adjust() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: ledvinap(a)gmail.com Target Milestone: --- Commit b048b7e (ITS#9388) introduced unaligned MDB_db* access. Cause: mdb_subdb_adjust dereferences an MDB_db * from NODEDATA(), which is not aligned Impact: undefined behavior in C. Incorrect page counts on ARM920T Fix: trivial, pass old as const void*, memcpy() into aligned stack variable Spotted/fixed by AI, so diff is not acceptable according to contribution rules. This report is fully authored by me. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

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

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

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

1 0

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

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

1 0

[Issue 10573] New: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10573 Issue ID: 10573 Summary: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap-msvc-673e3a64ee4f43(a)emalupe.com Target Milestone: --- OpenLDAP 2.7.0 fails to build with MSVC while generating the liblber symbol version map. The regression appears to have been introduced by commit 8651f98a08c37bea6ee9be78acececd52bac66a0 (ITS#9739). The new rules in libraries/liblber/Makefile.in and libraries/libldap/Makefile.in invoke: $(CPP) -x c -o $@ $(LT_CPPFLAGS) $(srcdir)/$(SYMBOL_VERSION_SCRIPT).in The -x c option is specific to GCC/Clang. When Autoconf's configured C preprocessor is MSVC (cl -E), cl ignores -x and treats the following c as an input filename: cl : Command line warning D9002 : ignoring unknown option '-x' c1: fatal error C1083: Cannot open source file: 'c': No such file or directory make[2]: *** [Makefile:301: lber.map] Error 2 This was reproduced with OpenLDAP 2.7.0 and Visual Studio 2026/MSVC 14.51 on Windows. OpenLDAP 2.6.13 builds successfully with the same compiler setup because it does not preprocess these map files. The same non-portable invocation is present in both the liblber and libldap map-generation rules and remains in the current OPENLDAP_REL_ENG_2_7 and master branches. Could the hard-coded compiler language option be removed or replaced with a configure-detected, compiler-portable way to preprocess the .map.in files? -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10617] New: Add an option to throttle when qtime exceeds a threshold
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10617 Issue ID: 10617 Summary: Add an option to throttle when qtime exceeds a threshold Product: OpenLDAP Version: 2.7.0 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: --- The first sign that a server is overloaded is that ops start spending longer time being queued before being executed. If the incoming load continues, the qtimes will continue growing. As such, an overload can be short-circuited before it gets completely out of hand by rejecting operations once their qtime exceeds a given threshold. We should add a config keyword to set a qtime threshold. When an operation hits the threshold it should be rejected. Note that we already implemented a feature like this experimentally for a private user, so we already know it is effective. In practice, qtimes on a healthy server are much less than 1msec. A qtime of 1msec would already indicate an overload condition. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10589] New: multiple issues with ppolicy rules and rehash in ppolicy
by openldap-its＠openldap.org 22 Oct '26

22 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10589 Issue ID: 10589 Summary: multiple issues with ppolicy rules and rehash in ppolicy Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 1202 --> https://bugs.openldap.org/attachment.cgi?id=1202&action=edit OpenLDAP Configuration Hello, I have tested recently the new ppolicy features of OpenLDAP 2.7.1. Thanks for this great work! The new features sound really exciting. Nevertheless, I have encountered some issues during testing. As these are new features, I don't know if this is a misconfiguration problem coming from me, or if there are bugs. You can find attached the configuration and data I have used. 1. I noticed that pwdPolicySubentry as static attribute is now deprecated. How could we assign directly a specific policy to a user in the future? 2. Using olcPPolicyRuleGroupAttr attribute in a scope rule generates a coredump while OpenLDAP tries to evaluate the assigned ppolicy. (ie during user entry loading). See the configuration. 3. I tried to configure a regex rule for assigning password policies. OpenLDAP crashes when trying to compute the assigned ppolicy. (when searching a user entry matching the policy). Maybe I have not correctly defined the regex rule, but I found no concrete example of this in documentation or unit tests. 4. Trying to run OpenLDAP in debug mode with TRACE level. (-d -1), whith given configuration and data makes OpenLDAP crash at startup, with no special log. It is due to scope and regex rules, as when I remove them, OpenLDAP starts normally. 5. For pwdRehashOnBind feature, I didn't understand the "If pwdReset is set to "TRUE"" part in the man page. The current behaviour I observed is that when pwdReset is TRUE, the password is never rehashed. What is the intent here? 6. When I try to modify a password from a user having a directly assigned ppolicy (pwdPolicySubentry defined statically), the password is never rehashed. Thanks in advance for your help! -- You are receiving this mail because: You are on the CC list for the issue.

1 13

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