openldap-bugs August 2026

openldap-bugs@openldap.org

1 participants
239 discussions

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure 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: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 30

[Issue 10257] New: Documentation assessment
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10257 Issue ID: 10257 Summary: Documentation assessment Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Created attachment 1031 --> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit Admin guide assessment Last month I commissioned a tech writer to review the current 2.6 Admin Guide to see what needs to be worked on before the 2.7 release. I'm attaching the report here so we can reference it. Should have distributed it sooner but Life got in the way. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10269] New: slap-constraint: Refactor to use a sorted array
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10269 Issue ID: 10269 Summary: slap-constraint: Refactor to use a sorted array Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As noted in the comments for slapo-constraint: /* * Linked list of attribute constraints which we should enforce. * This is probably a sub optimal structure - some form of sorted * array would be better if the number of attributes constrained is * likely to be much bigger than 4 or 5. We stick with a list for * the moment. */ -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10583] New: lloadd logging enhancements
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10583 Issue ID: 10583 Summary: lloadd logging enhancements Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- The logs do not contain the bind result or the identity of the caller which complicates troubleshooting issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 21 Oct '26

21 Oct '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 15

[Issue 10549] New: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10549 Issue ID: 10549 Summary: lloadd rejects proxied connections: proxyp() cannot read PROXY header on non-blocking socket Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: tim.wagner(a)freenet.de Target Milestone: --- # Overview When an lloadd listener is configured with the PROXY protocol enabled, a large fraction of incoming connections are dropped before they are accepted as clients. We're using HAProxy 3.4 (asme with 3.3, 3.2) to distribute the connections across 3 lloadd proxies. The log of lloadd fills with: ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The root cause is that `proxyp()` is written for a *blocking* socket, but the socket lloadd hands it is *non-blocking*. `proxyp()` (`servers/slapd/proxyp.c`) reads the PROXY header with a single synchronous `tcp_read()` that expects the whole header at once, and its retry loop only handles `EINTR`: ```c /* servers/slapd/proxyp.c:73 */ do { ret = tcp_read( SLAP_FD2SOCK( sfd ), (char *)&pph, sizeof(pph) ); } while ( ret == -1 && errno == EINTR ); if ( ret == -1 ) { ... "header read failed %d (%s)" ... /* EAGAIN lands here */ return 0; } ``` In lloadd, the accept callback runs on a non-blocking fd. The listener is created via libevent without `LEV_OPT_LEAVE_SOCKETS_BLOCKING`: ```c /* servers/lloadd/daemon.c:945 */ listener = evconnlistener_new( listener_base, lload_listener, ls, LEV_OPT_THREADSAFE|LEV_OPT_DEFERRED_ACCEPT, SLAPD_LISTEN_BACKLOG, ls->ls_sd ); ``` libevent's `evconnlistener` sets every accepted socket non-blocking unless that flag is set. `lload_listener()` then calls `proxyp( s, from, &dummy )` (`daemon.c:788`) synchronously, without ever making the fd blocking. So whenever the full PROXY header is not already buffered in the kernel at the moment the accept callback fires, `tcp_read()` returns -1/`EAGAIN`, `proxyp()` returns 0, and lloadd closes the connection. slapd is not affected: it `accept()`s the fd itself and calls `proxyp()` while the fd is still blocking (only the *listening* socket is made non-blocking, `servers/slapd/daemon.c:2624`; Linux `accept()` does not inherit `O_NONBLOCK`), so the single-shot reads block until the header arrives. # Actual Results Many connections are refused with (we see 7-12/s on every ldap proxy): ``` proxyp(<fd>): header read failed 11 (Resource temporarily unavailable) lload_listener: proxyp(<fd>) failed ``` The PROXY header is never parsed; the connection is closed. # Expected Results `proxyp()` should wait for the PROXY header to arrive (up to a timeout) on a non-blocking socket, parse it, and let the connection proceed — matching the behavior lloadd users get from slapd. # Additional Information (my speculation and assumptions) 1. **Primary trigger.** The specific errno-11 message requires an open, non-blocking fd with *zero* bytes buffered. A peer that completes the TCP handshake but has not yet sent the header produces exactly this. `TCP_DEFER_ACCEPT` (from `LEV_OPT_DEFERRED_ACCEPT`) reduces the race but does not remove it: its retransmit-based timeout delivers a data-less established connection, and health checkers/scanners that connect and stay silent hit the same path. (A peer that connects and immediately sends FIN would instead yield `ret == 0` → the "header read insufficient data" branch, not EAGAIN.) 2. **Latent secondary bug (same root cause).** Even when some bytes are present but not the full header, the non-blocking `tcp_read()` returns a short read, hitting the "header read insufficient data" branch (`proxyp.c:85`). A PROXY header split across TCP segments is therefore also rejected. The same applies to the address (`proxyp.c:129`) and options (`proxyp.c:206`) reads. 3. **Suggested fix direction.** Harden `proxyp()` for non-blocking sockets: on `EAGAIN`, `poll()`/`select()` for readability with a bounded timeout and retry; accumulate the header/address/options across partial reads instead of assuming a single `tcp_read()` delivers each field in full. This fixes both the EAGAIN rejection and the split-header rejection, and keeps proxyp() correct for both slapd (blocking) and lloadd (non-blocking) callers. (An alternative — temporarily setting the fd blocking around the proxyp() call in `lload_listener()` — is simpler but blocks the accept thread on a slow/malicious peer and still needs a timeout.) If you nee additional information please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9284] New: Need man page for vc contrib overlay
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9284 Issue ID: 9284 Summary: Need man page for vc contrib overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The verified credentials overlay in contrib is missing a man page describing its purpose -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

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 August 2026