openldap-devel

openldap-devel@openldap.org

1443 discussions

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

Error# '-4 Decoding error' with ldap_search_ext_s API
by venugopal chinnakotla 07 Jan '26

07 Jan '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 Decoding Error while making ldap_search_ext_s API under load. OpenLDAP C SDK API ldap_search_ext_s is giving -4 : Decoding error when we are making a search call to LDAP server (with SSL and without SSL) under load with multi threading. Here are few log messages related to -4: decoding error [10052/17636][ERROR]Error# '-4' during search: 'error: Decoding error' Search Query = '(cn=user1)' for server 'ldapserver1:10001' [10052/15624][ERROR]Error# '-4' during search: 'error: Decoding error' Search Query = '(cn=user2)' for server 'ldapserver1:10001' When we run the same load with NSLDAP, we are not getting any Decoding errors. Whenever we switch to OpenLDAP APIs and run the load, we are getting Decoding errors for few transactions under the load. Could you please look into this and provide any solution available for this issue? Thank you. -- Thanks, *c.venugopal*

1 0

searching dynamic values
by Emmanuel Dreyfus 06 Jan '26

06 Jan '26

Hello I am working on a overlay (the same as last time with the internal search question) that produce dynamic values depending on multiple attributes. The model was slapo-dynlist. I added an on_response method and I was able to produce everything needed when handling a search request. That works like a charm. But now I would like to use the generated values in a filter when searching. In some cases, I can modify the filter on the fly in bi_op_search so that it works, but that is not always possible. I thought of two alterantives: 1) In supann_op_add and supann_op_modify, perform an internal modify operation, so that the generated values are actualy added to the entry. But There is a problem: I exit that two methods without knowing if the add or modify operation succeded or not. The dynamic values should not be added if the add/modify operation failed. 2) I could steal some ideas from slapo-dds to update entries in the whole directory on a regular basis. That seems to do a lot of useless activity, and changes will always lag a bit. For now it seems to be the best option. Is there another was of doing it? -- Emmanuel Dreyfus manu(a)netbsd.org

3 7

Timeouts with ldap_search_ext_s and other APIS
by venugopal chinnakotla 09 Dec '25

09 Dec '25

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 timeouts, that we set LDAP Handle using ldap_set_option and calling an API ldap_search_ext_s. With Mozilla NSLDAP, setting PRLDAP_OPT_IO_MAX_TIMEOUT value to zero in LDAP Handle and making ldap_search_ext_s function call. Also passing timeout value (for Ex: 30 seconds) explicitly as one on the argument. This search call is giving an error: "Timeout error." With OpenLDAP, setting LDAP_OPT_TIMEOUT value to zero in LDAP Handle and making ldap_search_ext_s function call. Also passing timeout value (Same value: 30 seconds) explicitly as one of the arguments. This search call is giving a successful result instead of Timeout error. *Note:* With OpenLDAP, setting LDAP_OPT_TIMEOUT value to zero in LDAP Handle (0 sec, 1 microseconds) and making ldap_search_ext_s function call. Also passing timeout value 30 seconds explicitly as one of the arguments. This search call is giving a successful result instead of Timeout error. *Even tried this: *With OpenLDAP, setting LDAP_OPT_NETWORK_TIMEOUT value to zero in LDAP Handle (0 sec, 1 microseconds) and making ldap_search_ext_s function call. Also passing timeout value 30 seconds explicitly as one of the arguments. This search call is giving a successful result instead of Timeout error. --Here, I think LDAP_OPT_NETWORK_TIMEOUT is applicable only for connection calls. As per our application expected behaviour, with OpenLDAP, search call should give a timeout error, but it is giving a successful result. 1. What is the difference between the implementation of nsldap and OpenLDAP for timeouts? 2. If we want to get a Timeout error in the above use case (setting LDAP_OPT_TIMEOUT to zero) , what should we change with usage of OpenLDAP timeouts and APIs? 3. Also provide me some details on how timeouts are applied for each operation like connect/bind/search calls? 4. Which timeout will take the precedence/consideration when we have different timeouts, one is in LDAP Handle LDAP_OPT_TIMEOUT and another timeout value that we pass explicitly to ldap_searh_ext_s API? a. What happens when we have LDAP_OPT_TIMEOUT (ldo_tm_api in LDAP Handle) has less value than the timeout value specified in ldap_search_ext_s API argument explicitly? b. What happens when we have LDAP_OPT_TIMEOUT (ldo_tm_api in LDAP Handle) has greater value than the timeout value specified in ldap_search_ext_s API argument explicitly? 5. How do these timeouts apply to other API calls ldap_smple_bind_s? 6. Also, can you provide an equivalent timeout in OpenLDAP for Mozilla NSLDAP timeouts? LDAP_X_OPT_CONNECT_TIMEOUT - ( We mapped LDAP_OPT_NETWORK_TIMEOUT in OpenLDA) PRLDAP_OPT_IO_MAX_TIMEOUT - (We mapped LDAP_OPT_TIMEOUT in OpenLDAP) -- Thanks, *c.venugopal*

1 0

patch review
by Wall, Stephen 04 Dec '25

04 Dec '25

I’ve submitted a patch to OpenLDAP, but it doesn’t look like any action has been taken on it. Could a developer look at it and suggest changes, or commit it to the OpenLDAP repository? https://bugs.openldap.org/show_bug.cgi?id=10403 Thank you. -- Stephen Wall Senior Staff Software Engineer 585.924.7550 [cid:image001.png@01DC522C.BEE7E760] REDCOM Laboratories, Inc.<https://www.redcom.com/> Research, Engineering, & Development in Communications One Redcom Center, Victor, NY 14564-0995 https://bugs.openldap.org/show_bug.cgi?id=10403

2 3

Internal search
by Emmanuel Dreyfus 01 Dec '25

01 Dec '25

Hello I am working on a slapd overlay where I need to perform an internal search to validate a modify operation. It is roughtly the same situation as slapo-constraint with an url constraint type. In .bi_op_modify(), I piggy back on Operation with the code below. It works, my callback gets the entry, but when op2.o_bd->be_search() is called, the ldapmodify command gets this: ldap_modify: msgtype: expected 103 got 101 That is, LDAP_RES_SEARCH_RESULT instead of LDAP_RES_MODIFY: the search is not just insternal, its results are sent to the client. What did I do wrong? char filterstr[] = "(objectClass=*)"; Operation op2 = *op; SlapReply rs2 = { REP_RESULT }; (...) op2.ors_filterstr.bv_len = sizeof(filterstr); op2.ors_filterstr.bv_val = op->o_tmpalloc(op2.ors_filterstr.bv_len + 1, op->o_tmpmemctx); strcpy(op2.ors_filterstr.bv_val, filterstr); op2.o_dn = op->o_bd->be_rootdn; op2.o_ndn = op->o_bd->be_rootndn; op2.o_req_dn = op->o_req_dn; op2.o_req_ndn = op->o_req_ndn; op2.o_bd = select_backend(&op2.o_req_ndn, 1 ); op2.o_do_not_cache = 1; op2.o_tag = LDAP_REQ_SEARCH; op2.o_callback = NULL; op2.ors_limit = NULL; op2.ors_slimit = SLAP_NO_LIMIT;; op2.ors_tlimit = SLAP_NO_LIMIT; op2.ors_attrs = slap_anlist_no_attrs; op2.ors_attrsonly = 0; op2.ors_deref = LDAP_DEREF_NEVER; op2.ors_scope = LDAP_SCOPE_BASE; op2.ors_filter = str2filter_x( op, op2.ors_filterstr.bv_val ); cb.sc_response = supann_internal_search_cb; cb.sc_private = op; op2.o_callback = &cb; rc = op2.o_bd->be_search(&op2, &rs2); -- Emmanuel Dreyfus manu(a)netbsd.org

2 2

Re: LDAP race condition with ldap_initialize API in OpenLDAP 2.6.7
by Ondřej Kuzník 09 Sep '25

09 Sep '25

On Fri, Sep 05, 2025 at 02:47:52PM +0530, venugopal chinnakotla wrote: > 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 activity,we used ldap_initialize() API for > initializing and getting LDAP Handle. Our application supports multi > threading. So, ldap_initialize() API will be called from multi threaded > code. For example, 2 threads will call ldap_initialize() at same > time/simultaneously. > > When 2 threads call ldap_initialize() at same time, sometimes observed a > race condition during this API call. Due to this, the next api calls > ldap_simple_bind_s or ldap_start_tls_s are getting failed for 2 threads and > it is not recovered automatically until restarts our applications. We > observed this race condition multiple times. > > Because of this issue, we are unable to start our application and it > becomes a blocker for us to proceed further. > > After checking ldap_initialze() API code from openldap source code, noticed > that race condition happened while initializing/setting global options. > > Are there any known issues with OpenLDAP when we use it in multi thread > supported applications? > > Could you please check and provide a solution. Hi Venugopal, libldap documentation[0] explicitly asks that libldap initialisation be done in a thread safe way (=not concurrently as you're doing). Ignoring that (at your peril), you should be calling ldap_get/set_option() first to give the library a chance to initialise itself **before** you call ldap_initialize() to set up a new session, again as the documentation suggests. [0]. Quoting from https://openldap.org/software/man.cgi?query=ldap_initialize Note: the first call into the LDAP library also initializes the global options for the library. As such the first call should be single- threaded or otherwise protected to insure that only one call is active. It is recommended that ldap_get_option() or ldap_set_option() be used in the program's main thread before any additional threads are created. See ldap_get_option(3). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: Need information related to multi thread support in OpenLDAP c sdk client
by Ondřej Kuzník 09 Sep '25

09 Sep '25

On Fri, Sep 05, 2025 at 03:26:28PM +0530, venugopal chinnakotla wrote: > Hi Team, > > We are working on migration of nsldap C sdk to OpenLDAP c sdk for our > application client code. As part of this activity, replacing API one by one > and also looking for constant replacement. > > In NSLDAP C SDK: /* * Thread function callbacks (an API extension -- * > LDAP_API_FEATURE_X_THREAD_FUNCTIONS). */ #define LDAP_OPT_THREAD_FN_PTRS > 0x05 /* 5 - API extension */ > > Now, we are looking for similar functionality within OpenLDAP to use it in > our client program. I Went through OpenLDAP documents and source code, but > to my knowledge, did not get any equivalent one. > > Could you please provide more details on this to achieve equivalent > functionality of LDAP_OPT_THREAD_FN_PTRS with OpenLDAP? Hi Venugopal, in libldap, these functions are not runtime settable, the correct implementation is selected at compile time based on the target environment, usually PThreads or NT Threads. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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