openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

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

08 Sep '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 8

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

08 Sep '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 6

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

08 Sep '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 6

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

08 Sep '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 4

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

08 Sep '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 4

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 08 Sep '26

08 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=8149 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.1 |2.7.2 -- 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 08 Sep '26

08 Sep '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.1 |2.7.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 08 Sep '26

08 Sep '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 14

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

08 Sep '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.1 |2.7.2 -- 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 08 Sep '26

08 Sep '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 5

← Newer
1
2
3
4
5
6
7
8
...
2152
Older →

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