openldap-bugs June 2024

openldap-bugs@openldap.org

2 participants
66 discussions

[Issue 9886] New: At "sync" logging, nothing shows how long a write op took on consumers
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=9886 Issue ID: 9886 Summary: At "sync" logging, nothing shows how long a write op took on consumers Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If sync logging is enabled on a consumer, there's no etime logged which means it is not possible to see how long a write op took on that consumer. This can be useful information to see how the node is performing, particularly if it is a read only node where there will be no general MOD timing logged. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 09 Dec '24

09 Dec '24

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 4

[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
by openldap-its＠openldap.org 27 Nov '24

27 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10229 Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10235] New: Configure without --enable-nestgroup=no enables feature
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10235 Issue ID: 10235 Summary: Configure without --enable-nestgroup=no enables feature Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- OpenLDAP 2.6.8 configured with --enable-overlays. Some openldap commands output a Duplicate attributeType notice, for example # /sbin/slapcat -b cn=config -H ldap:///???olcTLSCertificateKeyFile=\* | grep olcTLSCertificateKeyFile register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 olcTLSCertificateKeyFile: /etc/certs/localhost/host.key Specifying configure option --enable-nestgroup=no prevents nestgroup feature and the message from being displayed. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10234] New: syncrepl does not reset the retrynum
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10234 Issue ID: 10234 Summary: syncrepl does not reset the retrynum Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- ``` syncrepl retry="5 10 30 +" ``` When replication fails with the above settings, syncrepl retries "10 times at 5 second intervals". Then, the retry count should be reset on the next replication failure. In actual, it does not reset. The behavior is as follows: ``` (first time replication failure) do_syncrepl: rid=001 rc -1 retrying (9 retries left) do_syncrepl: rid=001 rc -1 retrying (8 retries left) (resume replication) (second time replication failure) do_syncrepl: rid=001 rc -1 retrying (7 retries left) do_syncrepl: rid=001 rc -1 retrying (6 retries left) ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10218] New: Disabling and re-enabling an asyncmeta database via cn=config leaks memory
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10218 Issue ID: 10218 Summary: Disabling and re-enabling an asyncmeta database via cn=config leaks memory Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- To reproduce - run OpenLDAP with valgrind, and set the olcDisabled attribute of an asyncmeta database to TRUE, then again to FALSE. The connection structures of the database are subsequently shown as leaked. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10230] New: memberof addcheck must ignore other overlays
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10230 Issue ID: 10230 Summary: memberof addcheck must ignore other overlays 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: hyc(a)openldap.org Target Milestone: --- The addcheck feature added in ITS#10167 does a search to see if a newly added entry is already a member of any existing groups, and fixes its memberof attribute appropriately if so. The values written here should only be static values, but if the nestgroup overlay was configured, dynamic values were also being included. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10231] New: slapadd segfault on non-configured backend
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10231 Issue ID: 10231 Summary: slapadd segfault on non-configured backend Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If the LDIF being loaded corresponds to a different backend than the one specified (or the default backend, if none was specified), and the specified backend's configuration is incomplete and lacks a suffix, slapadd will SEGV when trying to print the error message about the LDIF not matching the specified backend, because it tries to print the suffix but the suffix is NULL. E.g. using this setup: ### mkdir dumb dumb/db cat > dumb/slapd.conf <<EOF include schema/core.schema backend ldif database ldif directory dumb/db EOF slapd -Ta -f dumb/slapd.conf -l schema/inetorgperson.ldif ### When fixed, the normal error message will be shown instead: slapadd: line 1: database #1 ((null)) not configured to hold "cn=inetorgperson,cn=schema,cn=config"; did you mean to use database #0 (cn=config)? Closing DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10221] New: Fix build script for 2.5.18
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10221 Issue ID: 10221 Summary: Fix build script for 2.5.18 Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- Hi, In revision 619afaccab5 (ITS#10177) an extra " was introduced, which will prevent configure script from working with FreeBSD's sh(1) (I suspect it would also break on other shell implementations). The fix is to delete that extra ". This affects OpenLDAP 2.5.18 only. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10223] New: tlso_ctx_cipherfree: does not check result of SSL_CTX_set_ciphersuites; can fail with incomplete input provided earlier on in the function
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10223 Issue ID: 10223 Summary: tlso_ctx_cipherfree: does not check result of SSL_CTX_set_ciphersuites; can fail with incomplete input provided earlier on in the function Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- The code on line 366 [1] doesn't check the return value of SSL_CTX_set_ciphersuites(..) before returning from the function, if there's leftover data in the tls13_suites buffer, after processing tls13_suites looking for TLS v1.3 compatible ciphers. OpenSSL doesn't state what specific scenarios could result in a failure with the function, but doing some code inspection [2] it appears that a failure could occur if the value provided in the second parameter (`str` per the manpage [3]) to SSL_CTX_set_ciphersuites(..) is either invalid or an internal memory allocation error occurs. While this isn't necessarily something that can be easily handled, it would be prudent to either ignore the return code explicitly by casting the result to (void) and clearing the error, or handling the OpenSSL error explicitly, using the ERR_* family APIs. This issue was reported by Coverity. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… 2. https://github.com/openssl/openssl/blob/5bbdbce856c7ca132e039a24a3156184848… 3. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html -- You are receiving this mail because: You are on the CC list for the issue.

1 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2024