openldap-bugs

openldap-bugs@openldap.org

1 participants
21567 discussions

[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9398 Issue ID: 9398 Summary: Stale accesslog cookie due to unclean shutdown Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db. Depending on the syncprov overlay checkpoint settings (usually no checkpointing is enabled on the accesslog db) this can cause the system to refuse engage in replication at startup. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10311] New: Work with IETF LDAP working group to update password hashing mechanism RFC
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10311 Issue ID: 10311 Summary: Work with IETF LDAP working group to update password hashing mechanism RFC Product: OpenLDAP Version: unspecified 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: --- Work with the IETF ldap working group to update the RFC to make the suggested hashing mechanism be what is currently "best practice" rather than a specific hashing mechanism. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10528] New: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9)
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10528 Issue ID: 10528 Summary: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9) Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lucas.vicente(a)ebz.tec.br Target Milestone: --- Hello, We are experiencing an issue while trying to load the core.ldif schema default using the dynamic configuration (cn=config). When using the following in my LDIF: include: file:///opt/symas/etc/openldap/schema/core.ldif I get this error: olcAttributeTypes: value #48 olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) slapadd: could not add entry dn="cn={0}core,cn=schema,cn=config" (line=14): olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) Obs: If I create a slapd.conf that includes the core schema and run: slaptest -f slapd.conf -F /tmp/slapd.d It works without errors. However, when trying to load the same schema using slapadd + include: in cn=config, it fails. For reference, I tested the same steps on version 2.6.10 and it worked without errors. Steps to reproduce: Install Symas OpenLDAP 2.6.13 on RHEL 9 Try to load the core schema using: dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///opt/symas/etc/openldap/schema/core.ldif Would you be able to verify this behavior? Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10423] New: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10423 Issue ID: 10423 Summary: It is possible via cn=config to add an entry of one database type with the object class of another, causing OpenLDAP to crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens specifically because the user by mistake attempts to create a meta database by specifying the object class for back-ldap. Since these share a lot of common attributes, schema checks do not fail. As a result, slapd initializes a meta database (based on olcDatabase value), but attempts to manipulate an initialized back-ldap database after that, and segfaults. Like this: dn: olcDatabase=meta,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: meta olcDbURI: "ldap://example.com" While it seems this is only possible for the proxy databases, we cannot rely that schema checks on attributes will fail for other database combinations, who knows what common attributes can be added or supplied in the future, we we have to fix this. The issue is reproducible via slapadd and at runtime with ldapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10641] New: Missing bound check on X.509 SAN string before wildcard matching
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10641 Issue ID: 10641 Summary: Missing bound check on X.509 SAN string before wildcard matching Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: xfding(a)google.com Target Milestone: --- In tls_o.c:1082, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… (sn[0] == '*') && (sn[1] == '.') was tested before checking ( sl > 1 ) Similarly, on 1191, https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… ( cnstr[0] == '*' ) && ( cnstr[1] == '.' ) also has a missing bound check ( cnlen > 1 ) Note that OpenSSL would stop null-terminating strings by default in the major releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 5738] back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=5738 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/941 Down the road we should also add support for deleting / unloading backends. The deleter can check to see if any databases have the backend in use, and return a failure in that case. Otherwise, it would be safe to unlink it from the list of backends and unload the module. -- 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 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8617 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE27: bc937c33 by Ondřej Kuzník at 2026-10-14T22:44:08+00:00 ITS#8617 slapo-rwm: Never instantiate under back-meta -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10495] New: Environment variable for Systemd is ignored by configure
by openldap-its＠openldap.org 14 Oct '26

14 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10495 Issue ID: 10495 Summary: Environment variable for Systemd is ignored by configure Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap.aftermost863(a)passinbox.com Target Milestone: --- Hello, When using the configure script to generate the Makefile, the documentation in the --help option states that the environment variable 'systemdsystemunitdir' can be used to override the default system path for Systemd units. However, this does not work: if I export the variable with a valid existing path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure, the variable is found but is ignored in the output variables and is therefore not used in the Makefile. config.log: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/usr/lib/systemd/system' ... The configure script seems to override that variable on line 23942: systemdsystemunitdir= I don’t quite understand why this line is there, and it seems suspicious to me. However, if I remove it and run ./configure again in the exact same shell, config.log now shows the correct path in the output variables, and the Makefile uses it correctly afterward: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... pkg_cv_systemdsystemunitdir=/tmp/test ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/tmp/test' I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh). -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 6761] contrib usn overlay broken
by openldap-its＠openldap.org 13 Oct '26

13 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=6761 --- Comment #2 from best(a)univention.de <best(a)univention.de> --- Thanks for this report. I wanted to experiment with it - and am affected as well. https://github.com/Free-IAM/freeiam/blob/v0.12.0/tests/Dockerfile#L24-L28 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
2157
Older →

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