openldap-bugs May 2026

openldap-bugs@openldap.org

1 participants
84 discussions

[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10424 Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base 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: elecharny(a)apache.org Target Milestone: --- Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: {0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry. Would I like to replicate, says, 'cn=config' with another syncrepl directive like: olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case). I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

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 30

[Issue 10509] New: 2.7: Feature notes for announcement file
by openldap-its＠openldap.org 04 Jun '26

04 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10509 Issue ID: 10509 Summary: 2.7: Feature notes for announcement file Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add feature notes for the 2.7 announcement file -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10508] New: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10508 Issue ID: 10508 Summary: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn Product: OpenLDAP Version: 2.6.13 Hardware: i386 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: apostnikov(a)gmail.com Target Milestone: --- Created attachment 1150 --> https://bugs.openldap.org/attachment.cgi?id=1150&action=edit 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch When syncrepl applies provider changes locally it invokes the backend through be_add / be_modify / be_modrdn / be_delete, carrying the provider's operational attributes in the modlist. Without `op->orm_no_opattrs = 1` the backend (verified on back-mdb; servers/slapd/back-mdb/modrdn.c:76 and modify.c:619) calls slap_mods_opattrs(), which auto-injects a `replace modifiersName=<op->o_dn>` mod whenever modifiersName is not already present in the modlist. For syncrepl, `op->o_dn` is the consumer's local rootdn (set at syncrepl.c:2165 — `op->o_dn = op->o_bd->be_rootdn`), so the consumer ends up with `modifiersName=cn=<consumer-rootdn>` instead of the provider's value. ITS#4820 originally papered over this in syncrepl_diff_entry() with a kludge that always forced modifiersName/modifyTimestamp into the diff (`if (*mods && (modifiersName||modifyTimestamp)) attr_cmp(NULL,new)`). ITS#10250 commit 87933f3e removed that kludge with the rationale "the mod is being passed to the backend with orm_no_opattrs these days". But two code paths in syncrepl.c never actually set orm_no_opattrs: 1. syncrepl_entry() refresh-mode rename-with-content path (around line 4788 on master): the parallel be_modify branch sets `orm_no_opattrs = 1/0` around its call; the be_modrdn branch does not. 2. syncrepl_message_to_op() (delta-sync log replay; whole function from line 3180 on master): none of the four backend dispatches (be_add, be_modify, be_modrdn, be_delete) set the flag. Once 87933f3e removed the kludge, the auto-inject surfaced whenever provider and consumer happened to already agree on modifiersName so syncrepl_diff_entry produced no mod for it. Whether that happens for a given entry depends on attribute iteration order in the diff (attribute hash bucket order), which is why x86_64/aarch64 mostly mask the bug while x86/armv7/armhf/s390x (QEMU builders) trigger it deterministically and ppc64le sees it as flake in test063. Worst case the consumer ends up with the provider's entryCSN (the modrdn bumped it) but the wrong modifiersName, and ITS#10358's assert-retry then sees identical entryCSN, takes no further action, and the corruption is permanent until something else updates the entry. Reproducer ---------------------------------------------------------------- Native: 32-bit or big-endian build of HEAD; run cd tests make BACKEND=mdb mdb-mod TESTS=test017-syncreplication-refresh Cross-arch via Alpine's CI image (any host): docker run --rm --platform linux/386 -v $PWD:/mnt \ registry.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci:latest-x86 \ sh -c 'cd /mnt && ./configure --enable-modules --enable-mdb=mod \ --enable-syncprov=mod && make && cd tests && make mdb-mod' Expected on affected builders: >>>>> Starting test017-syncreplication-refresh for mdb... ... test failed - provider and consumer databases differ >>>>> Failed test017-syncreplication-refresh for mdb Capturing the diff (modify defines.sh's CMPOUT temporarily) shows: 348c348 < description: Example, Inc. ITS test domain --- > description: Example, Inc. modify+modrdn test domain 350c350 < modifiersName: cn=Manager,dc=example,dc=com --- > modifiersName: cn=consumer,dc=example,dc=com (Both entries carry the SAME final entryCSN — that's the smoking gun: the consumer adopted the provider's CSN via the modrdn, but the follow-up modify hit `err=122 LDAP_ASSERTION_FAILED` because of the CSN bump, and ITS#10358's retry then short-circuited.) Proposed fix ---------------------------------------------------------------- Six added lines in servers/slapd/syncrepl.c — see attached patch 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch. Tested against OPENLDAP_REL_ENG_2_6_13: full make test suite passes on x86 (linux/386 QEMU) including all six tests that ITS#10250 patched plus test043-delta-syncrepl and test063-delta-multiprovider. References / related ITS ---------------------------------------------------------------- ITS#4820 — the original modifiersName/modifyTimestamp kludge added in 2007 ITS#10250 — kludge removed (MR#817, commit 87933f3e), exposing this bug ITS#10358 — assert-control retry (MR#781) — masks the divergence as silent data loss ITS#8852 — sorted_attr_cmp() prerequisite for ITS#10250 (commit 8986f99d) -- You are receiving this mail because: You are on the CC list for the issue.

1 10

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

03 Jun '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 6

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9739 Issue ID: 9739 Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/… I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Hence, creating the bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10514] New: another mutex bug in back-monitor
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10514 Issue ID: 10514 Summary: another mutex bug in back-monitor Product: OpenLDAP Version: unspecified 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: --- Same as #1710 but introduced later in 127ac65c447b8d28ba3cd75e1b8cee28006d5472 Calling mutex_destroy on a locked mutex in cache.c:314 monitor_cache_remove(). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10513] New: slapd segfault during shutdown when syncrepl is in retry mode
by openldap-its＠openldap.org 02 Jun '26

02 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10513 Issue ID: 10513 Summary: slapd segfault during shutdown when syncrepl is in retry mode 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: Marcelo.DeCastroLoebens(a)windriver.com Target Milestone: --- ## Problem slapd crashes with a segfault during shutdown. The crash occurs when the syncrepl provider is unreachable (syncrepl in retry mode). The issue has been observed twice under the same conditions. ## How to Reproduce 1. Configure slapd with syncrepl+TLS pointing to an unreachable host 2. Start slapd (syncrepl enters retry loop) 3. Send SIGTERM to slapd The crash is a race condition and does not occur often, but is reproducible with repeated attempts. ## Environment - OpenLDAP: 2.6.10 - OS: Debian 13 (Trixie), Linux 6.12, amd64 - OpenSSL: 3.5.1 - glibc: 2.41 ## Configuration slapd with back-mdb, syncrepl configured in refreshAndPersist mode with TLS, pointing to a provider that is unreachable (syncrepl in retry loop). mirrormode enabled, syncprov overlay loaded. Relevant slapd.conf excerpt: database mdb directory /var/lib/ldap syncrepl rid=000 provider=ldaps://peer-host tls_reqsan=demand type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=local" bindmethod=simple binddn="cn=admin,dc=example,dc=local" credentials=secret mirrormode TRUE overlay syncprov ## Stack Traces Two threads crash simultaneously: Two threads crash simultaneously: Thread 1 (main thread, PID 6946): #0 0x00007fe467381d91 (libcrypto.so.3 + 0x137d91) #1 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #2 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #3 0x00007fe4673822a5 (libcrypto.so.3 + 0x1382a5) #4 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #5 0x00007fe467382303 (libcrypto.so.3 + 0x138303) #6 0x00007fe467382133 (libcrypto.so.3 + 0x138133) #7 0x00007fe467382209 ASN1_item_free (libcrypto.so.3 + 0x138209) #8 0x00007fe467634ce9 X509_OBJECT_free (libcrypto.so.3 + 0x3eace9) #9 0x00007fe467601970 OPENSSL_sk_pop_free (libcrypto.so.3 + 0x3b7970) #10 0x00007fe46763528d X509_STORE_free (libcrypto.so.3 + 0x3eb28d) #11 0x00007fe4678c914e SSL_CTX_free (libssl.so.3 + 0x4614e) #12 0x0000563ee1c599b1 bindconf_free (/usr/sbin/slapd + 0x3d9b1) #13 0x0000563ee1ccf0e2 syncinfo_free (/usr/sbin/slapd + 0xb30e2) #14 0x0000563ee1c70d1c backend_destroy_one (/usr/sbin/slapd + 0x54d1c) #15 0x0000563ee1c70e6a backend_destroy (/usr/sbin/slapd + 0x54e6a) #16 0x0000563ee1c931c1 slap_destroy (/usr/sbin/slapd + 0x771c1) #17 0x0000563ee1c444c3 main (/usr/sbin/slapd + 0x284c3) #18 0x00007fe4679bbca8 (libc.so.6 + 0x29ca8) #19 0x00007fe4679bbd65 __libc_start_main (libc.so.6 + 0x29d65) #20 0x0000563ee1c45431 _start (/usr/sbin/slapd + 0x29431) Thread 2 (worker, TID 6948): #0 0x00007fe466dc9ae9 (back_mdb.so.2 + 0x29ae9) #1 0x00007fe467a22271 (libc.so.6 + 0x90271) #2 0x00007fe467a24a4e (libc.so.6 + 0x92a4e) #3 0x00007fe467aa27b8 (libc.so.6 + 0x1107b8) Kernel log: slapd[6948]: segfault at 7fe467c900c8 ip 00007fe466dc9ae9 sp 00007fe425bf4e80 error 7 in back_mdb.so.2.0.200 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2026