openldap-bugs

openldap-bugs@openldap.org

1 participants
21046 discussions

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 31 Oct '25

31 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10404] New: slapd uses all available memory and starts using swap
by openldap-its＠openldap.org 31 Oct '25

31 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10404 Issue ID: 10404 Summary: slapd uses all available memory and starts using swap Product: OpenLDAP Version: 2.6.10 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: tomas.bjorklund(a)su.se Target Milestone: --- We have a problem with slapd using more and more memory until in starts using swap. We are using mdb and our maxsize is set to 8192000000. The server has 32GB of ram. data.mdb is around 2.6 GB Some settings from our slapd.conf: sizelimit 5000 timelimit 600 checkpoint 1024 15 loglevel sync stats This is how it looks with top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 314486 root 20 0 31.6g 26.2g 2.6g S 16.3 83.7 8,09 slapd Depending on the load of the server it usually takes 2 weeks until all memory has been used. Things that we have tried: Changed swapiness to 1 Changed slapd service to use this: [Service] Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4" LimitCORE=infinity LimitNOFILE=4096 Restart=on-failure TimeoutStopSec=900 Everything worked fine with bdb and cache settings like: cachesize 100000 idlcachesize 100000 But since switching to mdb we run out of memory. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10402] New: Feature request: parameter for mdb_env_copy to exclude databases
by openldap-its＠openldap.org 30 Oct '25

30 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10402 Issue ID: 10402 Summary: Feature request: parameter for mdb_env_copy to exclude databases Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jeffro256(a)tutanota.com Target Milestone: --- ## Desired behavior New overload or API modification to `mdb_env_copy{...}()` which allows passing a list of names of databases to exclude from the environment copy. ## Example use-case The Monero blockchain database [1] has the option to derived a "pruned" database for space-saving purposes. This removes some ~60% of data which some users may find non-essential. Currently, the pruning code [2] copies each non-pruned table manually, specifying key ordering functions, DB flags, etc. It then drops some entries from the relevant "prunable tables". This, however, adds technical maintenance debt when databases are added/updated. A preferable alternative would be to write high-level modification code once and use an overload of `mdb_env_copy` which excludes copying database that we know in advance we don't want to copy. Then our pruning utility would work agnostic to database changes. ## Why Adding this functionality ourselves would involve re-writing large portions of `mdb_env_copyfd{0,1}` and `mdb_env_cwalk`, which requires either A) vendoring LMDB, or B) possibly breaking in future updates. You may understandably be of the opinion that the maintenance burden is an "us problem", and not deem pursuing this feature request worth it, but hopefully you seem the value in this utility. Thanks for y'alls hard work on LMDB. ## Links [1] https://github.com/monero-project/monero/blob/d32b5bfe18e2f5b979fa8dc3a8966… [2] https://github.com/monero-project/monero/blob/master/src/blockchain_utiliti… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 28 Oct '25

28 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[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 28 Oct '25

28 Oct '25

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 2

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 24 Oct '25

24 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10395 Issue ID: 10395 Summary: Support multiple readers on uncommitted changes Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1086 --> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit A patch to support multiple readers on uncommitted changes Hello, The attached patch is not meant to be merged immediately into LMDB. Still, it demonstrates how I added a helpful feature to the key-value store: reading uncommitted changes from multiple transactions. I am conscious that the patch still requires some work and uses non-C99 features, i.e., atomics are C11, which could be a blocker for it to be merged upstream. I would also be delighted to merge these changes under a flag/define to ensure we don't impact other users with non-C99 stuff. The main feature we need at Meilisearch is to read uncommitted changes from multiple threads, compute parallel post-processing of different data structures [1], and speed up the search requests. We could have done the post-processing in a following transaction by opening multiple read transactions, but this would mean that the post-processed data structure would not include newly inserted or modified document IDs. Both data structures would be desync. Regarding the design choice, I decided to follow the same design as the nested write transactions: use the parent argument of the mdb_txn_begin [2], and allow the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL [3]. I find it clear enough that, by calling the mdb_txn_begin function with these arguments, you can call it multiple times (I need to update the doc) to obtain nested read-only transactions from the parent write transaction. ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn); Note that this early proposal lacks security and error handling. The generated transactions are fake-read-only and actually write transactions that share the underlying parent allocations and data structures. This is unsafe and must be changed or reviewed carefully, but most importantly, we need to add read-only capabilities to these transactions to disallow writes. Using a Rust wrapper on top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which disallows any writes at compile time. However, I haven't checked the conflict database creations or openings. The main issues I encountered were concurrent free of the main shared data structures when the different threads owning the transactions were dropping the transactions simultaneously. So, I decided to implement the equivalent of an ARC to free resources only when the last nested transaction was freed. I can share numbers about how this feature improves the post-processing by 4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be happy to merge once an improved version of this patch lands on LMDB upstream. I would be very happy if you could guide me a bit on how I could improve this patch to make it mergeable into LMDB. We want to contribute useful features like this to LMDB and not keep a deviant fork. LMDB works great; we are happy about it, and its performance is predictable. Have a lovely week, kero [1]: https://github.com/meilisearch/meilisearch/pull/5307 [2]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… [3]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 21 Oct '25

21 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/800 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10398] New: memberof and refint clash on subtree renames
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10398 Issue ID: 10398 Summary: memberof and refint clash on subtree renames Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If a group and its members are under a subtree that got renamed, refint will trigger, and try to update all the relevant DNs. When it processes the group entry, it will issue Modifies to update the DNs of the group's members. The memberof overlay will see these modifies and start trying to update the corresponding memberof values but will only succeed halfway. It will try to delete the old memberof value from the old member DN's entry, which fails because the subtree has renamed all the entries. Then it will try to add the new memberof value to the new member DN's entry, which succeeds. Then eventually refint will try to process the member's. It will try to delete the old memberof value from the new entry, and add the new memberof value to the entry. This modify request fails because the new value is already present. The entry is left with a memberof value that points to the obsolete group DN. The solution is for refint to set the manageDsaIt control on its repair ops, and for memberof to ignore Modify requests with this control set. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10396] New: LMDB: another issue with sorted duplicate DBs and cursor delete
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10396 Issue ID: 10396 Summary: LMDB: another issue with sorted duplicate DBs and cursor delete Product: LMDB Version: 0.9.19 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In mdb_cursor_del0, in the second "Adjust other cursors" section (after mdb_rebalance was called), in these lines if (m3->mc_xcursor && !(m3->mc_flags & C_EOF)) { MDB_node *node = NODEPTR(m3->mc_pg[m3->mc_top], m3->mc_ki[m3->mc_top]); The node being referenced should be using mc->mc_top, not m3->mc_top. Most of the time these will be identical, but sometimes due to rebalancing, the mc cursor may be popped below its stack top when calling here. This bug was introduced for ITS#8406 in commit 37081325f7356587c5e6ce4c1f36c3b303fa718c on 2016-04-18. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10392] New: back-ldap does not return a response if incorrect secprops is configured
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10392 Issue ID: 10392 Summary: back-ldap does not return a response if incorrect secprops is configured Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- If a non-existent secprops mechanism is configured as part of a back-ldap idassert-bind directive, back-ldap does not return a response to the following requests, leaving the client waiting. In the same case meta and asyncmeta would return an LDAP error. My guess is failure to establish the target connection is handled incorrectly in that code path. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs