openldap-devel

openldap-devel@openldap.org

1 participants
1440 discussions

personal status & OL 2.7 release work
by Quanah Gibson-Mount 06 May '26

06 May '26

My main system I work from had a CPU failure. I'm currently getting it RMA'd (free, because this is apparently a known issue with some batches of the CPU). But it'll be next week before I'm fully back up and running. I'm working on getting things sync'd as able. I opened a PR to merge MDB 1.0 into mainline to prep it for 2.7. Ondrej, there was this pipeline failure that I think is odd, because it reports the test succeeded and then marks it failed: <https://git.openldap.org/quanah/openldap/-/jobs/20114> Not sure if it's related to the recent changes to the test suite. --Quanah

1 0

ITS#10489 potential 1-byte overread - is it a CVE or not?
by Howard Chu 11 Apr '26

11 Apr '26

IMO this doesn't qualify for a CVE and the reporter is just trying to pad his resume with fluff. In practice reads are non-destructive and 1 byte beyond an allocated buffer isn't going to break anything. Note that there is zero impact on slapd itself, because all of our uses explicitly pad one extra byte on message allocations. So this is only a potential problem for 3rd party users of liblber/ber_init2, a function that wasn't part of the old LDAP API RFC and is specific to OpenLDAP's liblber. I.e., no standard-compliant apps are using it. Any other opinions? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Performance degrade observed with OpenLDAP 2.6.7 library
by venugopal chinnakotla 12 Mar '26

12 Mar '26

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration, we are facing one issue related to performance degradation under load on Windows platform. In our application, we are using a single/shared connection handle to perform LDAP operation on LDAP user store servers. As part of Authentication, we are using ldap_search_ext_s call to get users and to get any user attributes from LDAP servers. We are using synchronous calls. With Mozilla NSLDAP, the same application is working well without any issues. As we are migrating to OpenLDAP, we did required changes and also we used ldap_dup() API to avoid "-4:Decoding error" issues under the load. Now, we are facing performance degradation issues under the load with OpenLDAP library Whenever we are trying to get a user attribute from the LDAP user store server where that user attribute is not available or value for user attribute is empty, we observed performance degradation with OpenLDAP library clearly around 25-30%. In case, search for user attributes with value, no degradation observed. This degradation is happening only when the user attribute is not available or the value is empty. Here are the snippet of runs output where performance degrade is showing: *With search of user attribute having value at LDAP server side:* Total Elapsed: 0:10:01 Minimum Response Time: 0:00:00.000.056 Maximum Response Time: 0:00:00.783.140 Average Response Time: 0:00:00.016.124 Total Requests: 659316 Throughput (Req/Sec): 1094.447 *With search of user attribute, not having value/does not exist at LDAP server side:* Total Elapsed: 0:10:01 Minimum Response Time: 0:00:00.000.059 Maximum Response Time: 0:00:00.218.502 Average Response Time: 0:00:00.032.788 Total Requests: 355065 Throughput (Req/Sec): 590.258 Example search calls we are using: 1. ldap_search_ext_x() for user lookup 2. ldap_search_ext_s() for user attributes for that specific user. (filter: uid=* and base: "cn=user,dc=comain,dc=com) - Where uid attribute has some value for this user at LDAP server side 3. ldap_search_ext_s() for user attributes for that specific user. (filter: Name=* and base: "cn=user,dc=comain,dc=com) - Where Name attribute is not present for that user at LDAP server side (This is causing performance degrade) With the same above steps, we did not see any performance issues with NSLDAP. If we remove step 3 from the above, no degradation is observed with the OpenLDAP library. Could you please look into this issue and provide a solution to overcome this performance degradation issue? We are completely blocked here as part of OpenLDAP migration. Note: To investigate this performance degradation with OpenLDAP, I wrote one LDAP sample code with the above 3 operations with multiple threads. I executed the sample with NSLDAP and OpenLDAP using multiple threads. In the sample runs, OpenLDAP is giving very poor performance when compared with NSLDAP. Please have a look at the sample also and provide your thoughts. Thank you in advance for your time and help

1 0

non-ASCII output for ldapsearch [PATCH]
by Emmanuel Dreyfus 27 Feb '26

27 Feb '26

Hello It would be nice if ldapsearch could display non-ASCII strings in a configurable charset, instead of always encoding in base64. I understand the current behavior is a requirement for LDIF compliance, but I believe we can add a non-LDIF compliant output, if this is what the user requested. Attached is a quick patch that will let ldapsearch output in the charset specified by LDAP_CHARSET environment variable (inspiration from LESS_CHARSET for less(1)). That makes life much more confortable when handling non-english data. It uses iconv() if <iconv.h> is detected. This function has been in POSIX for a while: https://pubs.opengroup.org/onlinepubs/007908775/xsh/iconv.html Opinions? Thoughts? -- Emmanuel Dreyfus manu(a)netbsd.org

2 1

[RESEND] Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 23 Feb '26

23 Feb '26

Dear OpenLDAP team, Apologies if this is a duplicate — I’m resending this message in case my previous post did not reach the list. I’m writing to ask for guidance on potential ongoing fuzzing and security contributions for OpenLDAP. This is not a bug report or patch submission. Brief context: we recently reported Bug 10429, which was fixed in MR 826 (thank you). We have since been applying our fuzzing infrastructure to OpenLDAP and integrated a set of LibFuzzer-based harnesses into OSS-Fuzz. Draft OSS-Fuzz integration: https://github.com/google/oss-fuzz/pull/14872 In addition to Bug 10429, several related issues identified through fuzzing have recently been reported to the Issue Tracking System by my collaborator Kang Yang (Issues 10445, 10446, 10447, 10448, 10449, and 10450), which further motivates broader and continuous fuzzing coverage. At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and patches will be submitted via the Issue Tracking System in accordance with the contribution guidelines. We would appreciate guidance on whether this OSS-Fuzz integration approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope or future in-tree fuzzing work. Thanks for your time. Best regards, Yunhang Zhang University of Utah

2 1

Modifying the modification
by Emmanuel Dreyfus 13 Feb '26

13 Feb '26

Hello In an overlay, I want to alter a modification operation so that modification to an attribute is not done. I crafted the code below, which seems to work, but is it right? There are XXX places where I expected another behavior, did I miss something? And after "Modifying the modification", I also have "Modifying an add", just below, with the same questions. /* Modifying the modification */ static void supann_rm_mods(Modifications *mods, Modifications **mods_prevp) { Modifications *mods_next = mods->sml_next; int freeit = 0; /* XXX Setting freeit to 1 crashes */ slap_mod_free(&mods->sml_mod, freeit); mods->sml_numvals = 0; free(mods); *mods_prevp = mods_next; return; } And this how it is used (of course removeit is a more complex logic, it is removed here for the sake of clarity) Modifications *mods; Modifications **mods_prev; Modifications *mods_next; mods_prev = &op->orm_modlist; for (mods = op->orm_modlist; mods; mods = mods_next) { short sm_op = mods->sml_op; Attribute a; mods_next = mods->sml_next; if (remove_it) supann_rm_mods(mods, mods_prev); else mods_prev = &mods->sml_next; } Same question, for add oprations: /* Modifying the add */ static void supann_rm_attr(Attribute *a, Attribute **a_prevp) { Attribute *a_next = a->a_next; attr_clean(a); #if 0 /* XXX This crashes */ free(a); #endif *a_prevp = a_next; return; } And its usage: Attribute **a_prev; Attribute *a_next; a_prev = &op->ora_e->e_attrs; for (a = op->ora_e->e_attrs; a; a = a_next) { a_next = a->a_next; if (removeit) supann_rm_attr(a, a_prev); else a_prev = &a->a_next; } -- Emmanuel Dreyfus manu(a)netbsd.org

2 4

Request for comment: allow ACLs to trigger based on op/controls
by Ondřej Kuzník 12 Feb '26

12 Feb '26

Dear community, for the next release, I've been preparing extensions to the ACL syntax to address a feature request that comes up relatively often - restrict access to data/actions based on what controls are involved. My thinking is that we could allow the following stanzas in the "access to <what>" part: - op=<operation name> or op=<OID> for extended requests - control=<OID> In here, we would probably provide a shorthand for known OIDs using the OID macro in schemas, so you could write something like this: ---- 8< ---- access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword control=ppolicy by anonymous auth access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword by group=cn=admin,ou=groups,dc=example,dc=com write by * none ---- 8< ---- As this is a deep change in how people work with ACLs, I'd like some feedback from the community at large before we commit to changing the syntax in a way that we have to live with for a long time. Have you needed something like this? Does the proposed addition solve your use-case? Can you see issues that are not covered or new ones that could crop up when used like this and might not be desirable? Any other feedback or proposals for how this could be expressed are also welcome. I'd like to add that this is unlikely to land until consensus has been achieved in the first place. For those happy to test actual code, the above proposal lives in a merge request: https://git.openldap.org/openldap/openldap/-/merge_requests/720 Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 09 Feb '26

09 Feb '26

Dear OpenLDAP team, My name is Yunhang Zhang, working with Prof. Jun Xu at the University of Utah (CS). We recently reported a NULL pointer dereference issue to OpenLDAP (Bug 10429), which was fixed in merge request [826](https://git.openldap.org/openldap/openldap/-/merge_requests/826) . Thank you for the prompt fix. I’m writing to discuss potential ongoing fuzzing and security contributions and to ask for guidance on the preferred process. We are part of the DARPA AI Cyber Challenge (AIxCC) finalist team “42-b3yond-6ug,” where we developed an AI-driven Cyber Reasoning System (CRS) that automatically generates fuzzing harnesses and discovers vulnerabilities in large C/C++ codebases. Applying this system to OpenLDAP so far, we have: * Generated LibFuzzer-compatible fuzzing harnesses targeting public OpenLDAP APIs * Validated the harnesses against documented interfaces * Integrated the harnesses into OSS-Fuzz for continuous testing Our draft OSS-Fuzz integration is available here: https://github.com/google/oss-fuzz/pull/14872 At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and corresponding patches will be submitted through the Issue Tracking System in accordance with the contribution guidelines. The goal is to improve long-term robustness and security coverage with minimal maintenance overhead for the OpenLDAP project. We believe broader fuzzing coverage can help detect regressions and subtle issues earlier over time. We would appreciate guidance from the community on whether this approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope, exclusions, or future in-tree fuzzing contributions. Thanks for your time and for maintaining OpenLDAP. Best regards, Yunhang Zhang University of Utah (on behalf of the 42-b3yond-6ug / DARPA AIxCC team)

1 0

slapd memory management revisited
by Howard Chu 09 Feb '26

09 Feb '26

Back when I first wrote sl_malloc, the idea was to grow the slab as needed and never have a free() method. Somewhere along the line this idea was shot down and we implemented free() anyway. I believe that was a mistake. If we get around to reimplementing this in 2.7 or 2.8, or 3.0... There should be these main classes of memory allocations: 1) per-server: this would mostly be config info, and any necessary per-database stuff. Can continue to use chmalloc/chfree. 2) per-connection: not much besides authc/authz. continue to use chmalloc/chfree. 3) per-operation: the BER structures for parsing an incoming request, plus any per-operation handling. This would use the equivalent of the current op->o_tmpmemctx. Would also include ACL cache, which is also relevant to an entire operation. 4) per-message: Only Search requests have multiple response messages. This would primarily be the structures needed to construct a search response. This would be a newly defined slab, which is reset before sending any search response. 5) per-function: Sometimes needed to allocate arrays used to return values from e.g. a normalization function. This would be a newly defined slab. We might continue to avoid the need for this, with the same trick we already use in libldap: do a pre-parse pass where we count the sizes of the values and arrays we need to return, and only allocate them after all sizes are known. The idea is that in routine operation, there is no need to call any kind of free() function. Just an occasional reset() on some slabs before they get reused. In practice, free() is more expensive than malloc() because it may have to walk many memory blocks to try to coalesce them, so it's of great benefit to eliminate any need for a free() function. As for growing the sl_malloc slab dynamically - this would be done without realloc. Instead just use a linked list of slab chunks, and allocate memory from the tail chunk. On slab reset, free all the chunks except for the initial one. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

[LMDB] Tag problem - update is needed
by * Neustradamus * 27 Jan '26

27 Jan '26

Dear OpenLDAP/LMDB team, There is an historical problem for Embedded Database LMDB (Lightning Memory-Mapped Database) source code. The latest LMDB version is 0.9.31 (2023-07-10): - https://github.com/LMDB/lmdb/tags Source: - https://www.symas.com/mdb A complete update is possible? At the same time, can you change your visibility from "Private" to "Public"? - https://github.com/orgs/LMDB/people - https://github.com/orgs/openldap/people Note: LMDB 0.9.30 is missing too. Thanks in advance. Regards, Neustradamus

1 0

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-devel