openldap-bugs

openldap-bugs@openldap.org

1 participants
21488 discussions

[Issue 10510] New: write_coherence can assert() on unbind
by openldap-its＠openldap.org 17 Aug '26

17 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10510 Issue ID: 10510 Summary: write_coherence can assert() on unbind 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 lloadd links a client with a backend and that client issues a write and unbind in quick succession, the self-checks in client_reset are overly strict, triggering an assert. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10570] New: Humble request for comment about cached pagination
by openldap-its＠openldap.org 14 Aug '26

14 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10570 Issue ID: 10570 Summary: Humble request for comment about cached pagination Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: f.castagnan(a)gmail.com Target Milestone: --- Hello folks, I hope you are well and thank you for providing a forum for users to raise inquiries, I think the structured format is quite good. (it's my first time doing raising an issue on your platform) Context: I have this query shape that is quite expensive, coming in from python ldap3 lib used in many of my clients. I decided to put openldap using the pcache overlay between my clients are my AD servers to cache the results. ```python # The python code using ldap3 python lib # Below expands to (&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=cn=<group>,ou=REDACTED,ou=REDACTED,ou=REDACTED,ou=REDACTED,dc=REDACTED,dc=com)) for entry in conn.extend.standard.paged_search( search_base, search_filter, scope, attributes=list(attributes), paged_size=page_size, generator=True, ): ``` I am using these attribute sets and templates (cropped for brevity) ``` ... database ldap suffix "dc=REDACTED" uri ldap://REDACTED.com/ overlay pcache pcache mdb 100000 6 1000 100 pcacheAttrset 0 uidNumber gidNumber sAMAccountName loginShell sn pcacheAttrset 1 member uidNumber gidNumber loginShell sAMAccountName memberOf cn name pcacheAttrset 2 whenCreated mail sAMAccountName cn objectclass whenChanged userprincipalname uidNumber objectGUID sn memberOf userPrincipalName userAccountControl pwdLastSet loginShell pcacheAttrset 3 cn name sAMAccountName memberOf uidNumber gidNumber distinguishedName unixHomeDirectory REDACTED pcacheAttrset 4 gidNumber sAMAccountName pcacheAttrset 5 name member gidNumber sAMAccountName cn pcacheTemplate (&(objectClass=)(gidNumber=)) 0 10800 pcacheTemplate (&(objectClass=)(gidNumber=)) 4 10800 pcacheTemplate (&(objectClass=)(cn=)) 1 10800 pcacheTemplate (&(objectClass=group)(cn=)) 1 10800 pcacheTemplate (sAMAccountName=) 0 3600 ... ``` Problem observed I can't seem to get the paged queries to be cached and it only returns my AD server max limit of 1000 items even when there are more results leading to inacurrate results in my clients. ``` # LOGS 6a7cd2f0.2447015f 0x7f65effff640 conn=53266 op=3 SRCH base="ou=REDACTED,dc=com" scope=2 deref=3 filter="(&(objectClass=user)(!(objectClass=computer)))" 6a7cd2f0.2447c7b1 0x7f65effff640 conn=53266 op=3 SRCH attr=unixHomeDirectory sAMAccountName REDACTED uidNumber gidNumber name cn distinguishedName memberOf 6a7cd2f0.24480fd2 0x7f65effff640 conn=53266 op=3: non-critical pagedResults control disabled with proxy cache; stripped. 6a7cd2f0.244819ea 0x7f65effff640 conn=53266 op=3: non-critical control "1.2.840.113556.1.4.1339" not supported; stripped. 6a7cd2f0.24484d6b 0x7f65effff640 query template of incoming query = (&(objectClass=)(!(objectClass=))) 6a7cd2f0.24485ba0 0x7f65effff640 QUERY NOT ANSWERABLE 6a7cd2f0.24486181 0x7f65effff640 QUERY NOT CACHEABLE ``` I tried a number of permutation to fix this, but upon inspecting the code it seems that pagination is explicitly not supported. From this line: https://github.com/openldap/openldap/blob/fe9c74b257398deab91ef2ec69011df3c… Questions: 1. Is there an accepted design for adding pagedResults support to pcache (cookie handling, stable ordering, cursor state)? 2. Is there a recommended way to cache paged searches or to internally page cached results while forwarding a single non‑paged search to the backend? 3. Are there existing patches or modules that solve this (or similar) in OpenLDAP? Many thanks! Francis -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10403] New: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap.
by openldap-its＠openldap.org 12 Aug '26

12 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10403 Issue ID: 10403 Summary: Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through that API with no changes in openldap. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- Created attachment 1090 --> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit Add a configuration directive that uses the OpenSSL CONF API to allow openldap config files to set any configuration supported by that API, and to get new OpenSSL configuration capabilities through th I am submitting a patch to create a new directive for OpenLDAP config files that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of OpenSSL that the API supports without adding specific directives to OpenLDAP for them. When OpenSSL extends that API, all versions of OpenLDAP with thie patch will also support those extensions with no additional code. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10562] New: Bug (and one possible fix) for MDB_RDONLY on a writable filesystem
by openldap-its＠openldap.org 11 Aug '26

11 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10562 Issue ID: 10562 Summary: Bug (and one possible fix) for MDB_RDONLY on a writable filesystem Product: LMDB Version: 1.0.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dan(a)shearer.org Target Milestone: --- Created attachment 1187 --> https://bugs.openldap.org/attachment.cgi?id=1187&action=edit Patch to fix docs in lmdb.h I found this problem in LumoSQL when following the LMDB documentation. From the MDB_RDONLY description of mdb_env_open: "Open the environment in read-only mode. No write operations will be allowed. LMDB will still modify the lock file - except on read-only filesystems, where LMDB does not use locks." Therefore, on writeable filesystems, MDB_RDONLY will still cause writes to a lockfile. This is a problem when a process wants read-only access to a database it has read permission on, but not write permission, such as unprivileged user reading a root-owned system database on an ordinary writable filesystem. Because the filesystem is writable, the lock file is opened O_RDWR|O_CREAT. For an unprivileged reader this returns EACCES. mdb_env_setup_locks() only tests for EROFS, so the open fails with EACCES (13). I suspect the minimal fix is to push the responsibility back onto the user (ie me in this case) and tell them in the documentation to add MDB_NOLOCK if they want read-only access on a writable filesystem. They also have to be very sure that there are no active writers, such as a root process somewhere else. I have attached a documentation patch for this. However, it's pretty harsh on the user because EACCES is a bit inscrutable, and fails the principle of least surprise. A minimal change to LMDB code would be to return something other than EACCES in this case so that the user is informed about what is happening, and can then decide whether MDB_NOLOCK is safe, or something else. Apart from that I can't think of what to do, due to safety issues. But this doesn't seem like an uncommon use pattern. I found it in LumoSQL when backing rpm with LMDB, where an unprivileged user can do a query while a root user is doing an update ( https://codeberg.org/LumoSQL/lumosql/src/branch/trunk/examples/rpm ). Best, -- Dan Shearer dan(a)shearer.org / https://shearer.org -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9786] New: liblber: missing export of ber_pvt_wsa_err2string
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9786 Issue ID: 9786 Summary: liblber: missing export of ber_pvt_wsa_err2string Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: tobias.junghans(a)veyon.io Target Milestone: --- When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked. This can be fixed easily by adding ber_pvt_wsa_err2string() to libraries/liblber/lber.map -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9816] New: slapcat cordeumps during mdb subtree dump with -s
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9816 Issue ID: 9816 Summary: slapcat cordeumps during mdb subtree dump with -s Product: OpenLDAP Version: 2.5.11 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: khoffmann(a)united-internet.de Target Milestone: --- Created attachment 887 --> https://bugs.openldap.org/attachment.cgi?id=887&action=edit gdb backtrace of slapcat run When trying to use slapcat in combination with -b and -s in order to create a LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the attached snippet with gdb output from a reproduced test tree). The problem was reporducible with different mdb databases / suffixes and only appears with option -s. The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is empty in the ldap-uri. Also using slapcat with -b only (for a full database dump) works fine as well. I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if you are going to fix this bug or if you rather take the change to remove the option completely from future major versions. Please let me also know if it's expected behaviour that the -H option doesn't work whenever the attribute part isn't empty and if I should contribute to a documentation update for this edge case. Best regards, Kris -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9972] New: SSS needs READ instead of SEARCH access
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9972 Issue ID: 9972 Summary: SSS needs READ instead of SEARCH access Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have configured an OpenLDAP 2.6 server with dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * search # no problem if this is READ olcAccess: to dn.sub="dc=aegee,dc=org" by * read … dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config objectClass:olcOverlayConfig The content of the tree is available anymously by calling ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub . When I modify the call to use SSS: ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 it also returns results, but ends with ``` # search result search: 93 result: 50 Insufficient access # numResponses: 3 # numEntries: 2 ``` When I modify above: olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * read then the access is sufficient. There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub` does not return it. These work without a problem: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E sss=ou:2.5.13.15 ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one This produces Insufficient access: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 That said client-side-sorting does work without a problem, but server-side sorting requires not only SEARCH, but also READ privileges on dn="cn=bodies,dc=aegee,dc=org". I find this is a bug: SSS requires read-acesss to data, which is not supposed to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the additional server-side sorting no additional privileges shall be required, compared to returning the results without server-side-sorting. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9748] New: Deleted values of pwdFailureTime seem to reappear
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9748 Issue ID: 9748 Summary: Deleted values of pwdFailureTime seem to reappear 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: --- Created attachment 854 --> https://bugs.openldap.org/attachment.cgi?id=854&action=edit accesslog for uid=dm01-R2H2-956,ou=People,dc=example,dc=com Somehow, ppolicy seems to be able to reference values of pwdFailureTime that had been deleted before the actual bind even started. In the attached accesslog, trace, deletion of everything (including "20211115154510.478330Z") is recorded from reqSession: 3, then a bind comes in and the same value is explicitly removed again. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9902] New: Make max index DBs for back-mdb configurable
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9902 Issue ID: 9902 Summary: Make max index DBs for back-mdb configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From ITS#9895: Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites want more than this (although there's no evidence they actually use more than 128 attributes in all of their applications' search filters). For 2.5/2.6 we can simply double the constant. For 2.7 consider making it configurable. Note that increasing the number increases the size of an LMDB transaction structure, and also increases the time needed to initialize it whenever creating a transaction, so it's a bad idea to just set this to an arbitrarily large number. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10332] New: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10332 Issue ID: 10332 Summary: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Please add support to do the following: SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://... Other libraries and tools support it to decrypt the TLS traffic with Wireshark for analysis purposes. Curl has a simple, but complete implementation: https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/… Maybe it can be reused if license allows that?! -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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