openldap-bugs February 2025

openldap-bugs@openldap.org

1 participants
51 discussions

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

25 Mar '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 8

[Issue 10266] New: Adopt broader RFC4511 NoD interpretation on lloadd's client side
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10266 Issue ID: 10266 Summary: Adopt broader RFC4511 NoD interpretation on lloadd's client side Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Server side, lloadd has long implemented a broad interpretation of NoD unsolicited response handling: when the message is issued, no new requests are accepted on the session however the client and server are both free to keep the session open if there are any operations that have not resolved yet. The server is still expected to close the connection as soon as no operations are still pending. This seems to interoperate with known clients. Those that want to will close the session immediately, unaware of this possibility, those that also want to interpret RFC 4511 this way can choose to wait for existing operations to resolve. This ticket is to track the lloadd's implementation of the client side of this - when receiving a NoD message, we don't close the connection immediately+unconditionally either but are willing to wait. Related functionality: - if connection was a bind connection processing a multi-stage SASL bind, the bind should fail if/when the client attempts to progress it - clients assigned to this connection through coherence at least 'connection' are also marked closing -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10310] New: Update pbkdf2 overlay so iterations can be configurable
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10310 Issue ID: 10310 Summary: Update pbkdf2 overlay so iterations can be configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The pbkdf2 password hashing contrib overlay has the number of iterations hard coded at 10,000. It would be helpful to update the module to allow this to be configurable instead, as is done with other password hashing modules. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10314] New: Only install the slapi-plugin.h header if building slapi library
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10314 Issue ID: 10314 Summary: Only install the slapi-plugin.h header if building slapi library Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mattias.ellert(a)physics.uu.se Target Milestone: --- Created attachment 1054 --> https://bugs.openldap.org/attachment.cgi?id=1054&action=edit Proposed patch The slapi-plugin.h header does not make sense without the slapi library. The attached patch makes the installation of the header conditional. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10305] New: pkg-config should be used to find cyrus-sasl
by openldap-its＠openldap.org 25 Feb '25

25 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10305 Issue ID: 10305 Summary: pkg-config should be used to find cyrus-sasl Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hi(a)alyssa.is Target Milestone: --- Static libraries do not encode their dependencies, so dependencies have to be discovered using pkg-config or another equivalent mechanism. OpenLDAP does not use pkg-config to find cyrus-sasl, which means that even if a working static cyrus-sasl library is available, it won't be used, because OpenLDAP's build system won't know to link its dependency libraries. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10311] New: Work with IETF LDAP working group to update password hashing mechanism RFC
by openldap-its＠openldap.org 25 Feb '25

25 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10311 Issue ID: 10311 Summary: Work with IETF LDAP working group to update password hashing mechanism RFC 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: --- Work with the IETF ldap working group to update the RFC to make the suggested hashing mechanism be what is currently "best practice" rather than a specific hashing mechanism. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 21 Feb '25

21 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10024 Issue ID: 10024 Summary: MDB_PREVSNAPSHOT broken Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: markus(a)objectbox.io Target Milestone: --- It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT. In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd latest) commit is not selected. Instead, reads show that the latest commit was selected voiding the effect of MDB_PREVSNAPSHOT. I observed this in our test cases a while back. Today, I was finally able to reproduce it and debug into it. When creating the transaction to read the data, I debugged into mdb_txn_renew0. Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0 (!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting the first (index 0) meta page inside mdb_txn_renew0: meta = env->me_metas[txn->mt_txnid & 1]; This line occurs twice (once for read txn and once for write txn; it affects both txn types). Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50. It's only correct if the first meta page (index 0) is the older one. I believe that this is related to #9496 because the patch, that was provided there, removed the initialization of "env->me_txns->mti_txnid" in mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was set to 0. I can confirm that adding back the following two lines back in fixes MDB_PREVSNAPSHOT: if (env->me_txns) env->me_txns->mti_txnid = meta.mm_txnid; The said patch including the removal of these two lines was applied in the commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21). I hope this information is useful to find a suitable fix. Please let me know if you have questions. Also, I'd be happy to help confirming a potential fix with our test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10265] New: Make it possible to change olcBkLloadListen at runtime
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10265 Issue ID: 10265 Summary: Make it possible to change olcBkLloadListen at runtime Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Currently, olcBkLloadListen changes only take effect on lloadd startup: - an added olcBkLloadListen should come online at the end of the modify operation - at the end of the modify operation a removed olcBkLloadListen will stop listening on the sockets associated with it, clients that connected over these are marked CLOSING - to facilitate replacing a value where URIs resolved sockets overlap, olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass Lloadd's startup was modelled upon slapd's, but the requirements have changed considerably when it was turned into a module. Sockets are acquired at module configuration time, which is much later than standalone/slapd's own startup and so the way the URLs are handled also needs to be reworked. This will resolve other related issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta… With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2025