openldap-bugs October 2026

openldap-bugs@openldap.org

1 participants
73 discussions

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=7335 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

[Issue 9002] Document correct procedure for generating usable backups via slapcat
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=9002 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10217] New: autoca should support more key types
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10217 Issue ID: 10217 Summary: autoca should support more key types Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently autoca only creates certificates using RSA keypairs. It should at least have an option to use Elliptic Curve keypairs. It probably also needs options to specify other signature algorithms other than the default of SHA256. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10277] New: How to deal with desync between cn=config and back-ldif DNs
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10277 Issue ID: 10277 Summary: How to deal with desync between cn=config and back-ldif DNs 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 someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected. Right now the only remedy is slapcat+slapadd of the whole config DB, is that the best we can do? When we detect this (doesn't always happen), should we fix the on-disk copy on startup? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8476] slapo-constraint: info per constraint_attribute
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8178] back-sock: Timeout to avoid locking
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8178 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.2 |2.7.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10622] New: pcache: add option to passthru pagedResults searches
by openldap-its＠openldap.org 21 Oct '26

21 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10622 Issue ID: 10622 Summary: pcache: add option to passthru pagedResults searches Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently pcache just silently ignores the pagedResults control, but clients setting the control aren't expecting the unpaged search responses. Add an option for pcache to pass the search through unmodified (and uncached). -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2026