openldap-bugs July 2025

openldap-bugs@openldap.org

1 participants
109 discussions

[Issue 10335] New: [PATCH] ldapsearch: fix handling of -LL in print_reference()
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10335 Issue ID: 10335 Summary: [PATCH] ldapsearch: fix handling of -LL in print_reference() Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: bolek(a)live.com Target Milestone: --- Created attachment 1066 --> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit [PATCH] ldapsearch: fix handling of -LL in print_reference() I, Boleslaw Ciesielski, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The attached patch (against master) fixes a bug in ldapsearch where the -LL (or -LLL) option is ignored when printing the reference comments in print_reference(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests 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: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10377] New: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10377 Issue ID: 10377 Summary: The words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- In '8.4.8. Allowing entry creation' section, the DIT example is 'ou=addressbooks'. On the other hand, the ACL example is 'ou=addressbook,'. So the words (addressbooks/addressbook) seems to be mismatched in the DIT example and the ACL example. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10374] New: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10374 Issue ID: 10374 Summary: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, As a follow-up from https://bugs.openldap.org/show_bug.cgi?id=10373, it appears that the configuration I had shared can be converted to olc with slaptest, however does not pass validation be loaded when the daemon start: ``` $ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d $ slaptest -u -F /etc/openldap/slapd.d -d stats -d pcache unrecognized log level "pcache" (deferred) Total # of attribute sets to be cached = 16. Template: query template: (mail=) attributes: * + Template: query template: (objectClass=*) attributes: * + Template: query template: (objectClass=*) attributes: mail Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (jid=) attributes: jid config error processing olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid (0->15) slaptest: bad configuration directory! ``` From the following slapd.conf: ``` overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # No TTR, see https://bugs.openldap.org/show_bug.cgi?id=10373 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 pcacheTemplate (objectClass=*) 0 3600 60 0 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 pcacheTemplate (objectClass=*) 2 3600 60 0 pcacheTemplate (objectClass=) 2 3600 60 0 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 pcacheTemplate (mail=) 5 3600 60 0 ``` The following olc configuration get generated ``` $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache/olcDatabase={0}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 20578f61 dn: olcDatabase={0}mdb objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: /var/lib/openldap-data/pcache olcDbNoSync: FALSE olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 structuralObjectClass: olcMdbConfig entryUUID: ff5661e1-1259-4408-89a8-68f3c1b36095 creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a8cfafe8 dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: mdb 65536 16 1024 60 olcPcacheAttrset: 1 jid olcPcacheAttrset: 2 ou cn givenName sn mail telephoneNumber jid description jp egPhoto objectClass olcPcacheAttrset: 3 ou cn givenName sn mail telephoneNumber description jpegPh oto objectClass olcPcacheAttrset: 4 mail olcPcacheAttrset: 5 * + olcPcacheTemplate: "(mail=)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 4 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 3 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 2 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 2 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 2 3600 60 0 0 olcPcacheTemplate: "(jid=)" 1 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 0 3600 60 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 1024 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE structuralObjectClass: olcPcacheConfig entryUUID: dbee2888-2741-4298-abc3-81ae4bd9433a creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z ``` Is this a known limitation at the moment ? Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10345] New: Potential memory leak in function rbac_create_session
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10345 Issue ID: 10345 Summary: Potential memory leak in function rbac_create_session Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- In `rbac_create_session`, we have the following code: ```c if ( rc < 0 ) { rs->sr_err = LDAP_OTHER; rs->sr_text = "internal error"; } else { (void)ber_flatten( ber, &rs->sr_rspdata ); rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first rs->sr_err = LDAP_SUCCESS; } ber_free_buf(ber); done:; // always put the OID in the response: rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second ``` The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without freeing the previous string, resulting in a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10343] New: Potential Memory Leak in function slap_uuidstr_from_normalized
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10343 Issue ID: 10343 Summary: Potential Memory Leak in function slap_uuidstr_from_normalized Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1070 --> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit Patch: Change 1 to -1. In function slap_uuidstr_from_normalized, the code allocates a new `struct berval` with ```c new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx); ``` and then attempt to allocate `new->bv_val`. If that second allocation fails, it sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code only runs when `rc == -1`, so the memory pointed by `new` is never freed, causing a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10359] New: delta-MPR uses logbase for more than it documents
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10359 Issue ID: 10359 Summary: delta-MPR uses logbase for more than it documents Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but also for internal searches when it comes to delta-MPR conflict resolution. This is not documented so an admin doesn't know that the local accesslog DB needs to exist and have the same suffix. Either the documentation needs updating or a new configuration item needs to be added to allow an accesslog DB with a different suffix locally. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10367] New: Article for 'Asynchronous Metadirectory backend' seems to be typo.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10367 Issue ID: 10367 Summary: Article for 'Asynchronous Metadirectory backend' seems to be typo. Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- In the table of '6.2.2.1. backend <type>'section on this page(https://www.openldap.org/doc/admin26/slapdconfig.html), the description about asyncmet is 'a Asynchronous Metadirectory backend', but I think that this is 'an Asynchronous Metadirectory backend'. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2025