openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
94 discussions

[Issue 10168] New: olcdbindex doesn't cleanup cleanly
by openldap-its＠openldap.org 01 Apr '25

01 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10168 Issue ID: 10168 Summary: olcdbindex doesn't cleanup cleanly 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 you run the following modify against slapd (notice the olcDbMultival data is wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the olcDbIndex changes: dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: member eq olcDbIndex: memberof eq - add: olcDbMultival olcDbMultival: member,memberOf 5,15 - -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10169] New: Add support for token only authentication with otp overlay
by openldap-its＠openldap.org 27 Mar '25

27 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10169 Issue ID: 10169 Summary: Add support for token only authentication with otp overlay Product: OpenLDAP Version: 2.6.6 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: --- Currently the OTP overlay is password + token. It would be nice to be able to configure it so it can run in a token only mode, similar to the slapo-totp overlay in contrib. This would allow us to have a project supported solution and retire that contrib module. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10020 Issue ID: 10020 Summary: dynlist's @groupOfUniqueNames is considered only for the first configuration line Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- If we consider the following configuration of dynlist: {0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames The {0} entry will correctly populate the memberOf relatively to static group membership. The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration - or - remove @groupOfUniqueNames part from this configuration line, then both dynamic and static entries will be populated correctly for {1}. So the effects are as follows on some user entry: if both {0} and {1} are present - {1} produced only dynamic groups: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl If only {1} is present - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl For completness - if only {0} is present: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl I would expect this behavior to be correct for the first case - {0} and {1}. memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 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: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10258] New: test050 failure: connection_close race?
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10258 Issue ID: 10258 Summary: test050 failure: connection_close race? 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: --- Created attachment 1032 --> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit tail of slapd log Running test050 repeatedly, the slapd managed to get itself into an apparent inconsistency in the connections structure. The logs suggest that there might be a race closing the connection. Unfortunately the sanitiser didn't initiate a core dump in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[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 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

[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 September 2024