openldap-bugs September 2023

openldap-bugs@openldap.org

1 participants
91 discussions

[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9378 Issue ID: 9378 Summary: Crash in mdb_put() / mdb_page_dirty() Product: LMDB Version: 0.9.26 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: nate(a)kde.org Target Milestone: --- The KDE Baloo file indexer uses lmdb as its database (source code available at https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100 duplicate bug reports, is in lmdb. Here's the bug report tracking it: https://bugs.kde.org/show_bug.cgi?id=389848. The version of lmdb does not seem to matter much. We have bug reports from Arch users with lmdb 0.9.26 as well as bug reports from people using many earlier versions. Here's an example backtrace, taken from https://bugs.kde.org/show_bug.cgi?id=426195: #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79 #8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600, expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0", func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty", line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542 #9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>, txn=0x55e2ad7109f0) at mdb.c:2114 #10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114 #11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308 #12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:2495 #13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:6523 #14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:6657 #15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:9022 #16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put (this=this@entry=0x7f3c0727b960, docId=<optimized out>, docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79 #17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument (this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at ./src/engine/writetransaction.cpp:232 #18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument (this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at ./src/engine/transaction.cpp:295 #19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run (this=0x55e2ad79ca20) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at thread/qthreadpool.cpp:99 #21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at thread/qthread_unix.cpp:361 #22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #23 0x00007f3c0bcb6103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 10100] New: Non-sequential timestamps being logged on Windows
by openldap-its＠openldap.org 16 Feb '24

16 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10100 Issue ID: 10100 Summary: Non-sequential timestamps being logged on Windows Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Presents as a dsync during replication. Consumer will log ``` 650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring 20230920131409.040136Z#000000#001#000000 (uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com) ``` The entry was not be added. The provider will log messages using non-sequential timestamps. For example, when grepping the CSN from above (in provider log): ``` # This: 650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002, cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000 # and: 650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new csn=20230920131409.040136Z#000000#001#000000 manage=1 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9823] New: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9823 Issue ID: 9823 Summary: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Configured w/ deltasync. When a consumer goes offline for a duration exceeding the the logpurge interval, won't fallback into syncrepl, resulting in a dsync. -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9795] New: Remove memberof overlay
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=9795 Issue ID: 9795 Summary: Remove memberof overlay Product: OpenLDAP Version: 2.6.1 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: --- The memberof overlay was deprecated with the release of OpenLDAP 2.5. It should be removed prior for the next minor release (i.e., 2.7) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10014] New: TLS handle using MbedTLS
by openldap-its＠openldap.org 30 Jan '24

30 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10014 Issue ID: 10014 Summary: TLS handle using MbedTLS Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: johan.pascal(a)linphone.org Target Milestone: --- Created attachment 950 --> https://bugs.openldap.org/attachment.cgi?id=950&action=edit Add a TLS handle using MbedTLS Hi, I wrote a TLS handle based on MbedTLS. I attach the patch here but I can also put in on gitlab and make a merge request there. The patch contains the minimal modifications to build openldap using MbedTLS as backend for TLS. You must run aclocal, autoheader amd autoconf to regenerate the archived aclocal.m4, configure and include/portable.hin files. This contribution was originally written for the linphone project, and copyright belongs to Belledonne Communications SARL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Belledonne Communications SARL. Belledonne Communications SARL has not assigned rights and/or interest in this work to any party. I, Johan Pascal am authorized by Belledonne Communications, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010-2023 Belledonne Communications SARL Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10080 Issue ID: 10080 Summary: refreshAndPersist synchronization problem with glue + rwm Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: homma(a)allworks.co.jp Target Milestone: --- Created attachment 972 --> https://bugs.openldap.org/attachment.cgi?id=972&action=edit Stack trace of segfault I have an openldap 2.6.2 server "ldap1" with the following DIT: dc=example,dc=com (back-mdb) ou=users ou=local cn=admin cn=sync ... ou=remote (back-ldap -> ldaps://dc1.example.com) ... Local user entries are created under subtree "ou=local,ou=users,dc=example,dc=com", and the subtree "ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server "dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com"). The concrete configuration is as follows: ---------------- dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: ou=remote,ou=users,dc=example,dc=com olcSubordinate: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbURI: ldaps://dc1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com" credentials=secret tls_reqcert=demand mode=none olcDbIDAssertAuthzFrom: {0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbIDAssertAuthzFrom: {1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com" olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson olcRwmMap: {1}objectclass posixAccount user olcRwmMap: {2}attribute uid sAMAccountName olcRwmMap: {3}attribute homeDirectory unixHomeDirectory olcRwmMap: {4}attribute ou * olcRwmMap: {5}attribute cn * olcRwmMap: {6}attribute sn * olcRwmMap: {7}attribute givenName * olcRwmMap: {8}attribute mail * olcRwmMap: {9}attribute uidNumber * olcRwmMap: {10}attribute gidNumber * olcRwmMap: {11}attribute * dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcAccess: {0}to * by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write by * break olcAccess: {1}to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2}to * by * read olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub ---------------- So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both local and remote users. But when I create the second server "ldap2" with similar configuration and configure refreshAndPersist replication, I run into a problem. (1) When I configure on "ldap1" server, ---------------- dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ---------------- and on "ldap2" server, ---------------- dn: olcDatabase={3}mdb,cn=config changeType: modify replace: olcSyncrepl olcSyncrepl: {0}rid=301 provider="ldap://ldap1/" bindmethod=simple binddn="cn=sync,ou=local,ou=users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 12 60 +" timeout=1 ---------------- the initial refresh stage fails. (a) Whith the above configuration, the refresh failes with "(48) Inappropriate authentication", because the bind DN "cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the subordinate database. (b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with "(12) Critical extension is unavailable", because Active Directory does not support Sync Request Control. (c) Even if the remote server supports Sync Request Control, the refresh fails with the message "server sent multiple refreshDone messages? Ending session". The refreshDone messages are sent twice, one for the sperior databese and the other for the subordinate database. (d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify delete: olcSubordinate ---------------- then the refresh stage completes successfully. Once the persistent session is established, I can add olcSubordinate attribute again. ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcSubordinate olcSubordinate: TRUE ---------------- When I modify entries in the subordinate database on "ldap1" server, no change notification is sent to "ldap2" server. This is the desired behavior, but if I restart slapd on "ldap1" server, the refresh starts failing again. (2) When I configure the glue overlay explicitly before the syncprov overlay, as described in "man slapd-config", ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. This is fine because I do not need to synchronize the subordinate database between "ldap1" and "ldap2" servers. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault. See the attached file for stack trace. After some research, I found that the cause of the crash is as follows: In syncprov_matchops(), it attempts to get the modified entry with DN = op->o_req_ndn. But since op->o_req_ndn has been rewritten in the rmw overlay, glue_back_select() incorrectly selects the mdb backend, which should be the ldap backend. At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but mdb_entry_get() tries to interpret it as type struct mdb_info, causing a segfault. In summary, the problem is: When I configure refreshAndPersist synchronization for a database with a subordinate ldap backend using DN rewriting, (1) The subordinate database cannot be excluded from both refresh and persistent stage of the synchronization: When the glue overlay is not explicitly configured: - In the refresh stage, the subordinate database is included in the search. - In the persist stage, the subordinate database is excluded from the synchronization. When the glue overlay is explicitly configured before the syncprov overlay: - In the refresh stage, the subordinate database is excluded from the search. - In the persist stage, the subordinate database is included in the synchronization. This seems to be inconsistent. (2) If the subordinate database is included in the refresh stage, the refresh fails for one of the following reasons: - the syncrepl user is not allowed to access the subordinate database - the remote server does not support Sync Request Control - multiple refreshDone messages are returned The refresh stage completes successfully if olcSubordinate attribute is deleted from the subordinate database. olcSubordinate attribute can be added again once the persistent session is established, but the refresh stage starts failing again if slapd is restarted. (3) If the subordinate database is included in the persist stage, modifying entries in the subordinate database causes slapd to crash. -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10098] New: contrib modules don't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10098 Issue ID: 10098 Summary: contrib modules don't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Need a couple tweaks to the Makefiles. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10092] New: Local logging doesn't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10092 Issue ID: 10092 Summary: Local logging doesn't build on Windows Product: OpenLDAP Version: 2.6.6 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: --- slapd/logging.c uses writev() to write a prefix and the log message together in one call. This feature doesn't exist on Windows. The closest equivalent, WriteFileGather, only works on page sized and aligned writes. On Windows the only way to write as desired is to copy the message into a new buffer first. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10074 Issue ID: 10074 Summary: lloadd: build broken with more recent versions of LLVM Product: OpenLDAP Version: 2.6.4 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- There are two issues preventing lloadd from building with more recent versions of LLVM. These are discovered on FreeBSD but may affect other operating systems too. The first one is that ldap_pvt_thread_self is returning pthread_t (which is a pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was expecting unsigned long. A possible solution would be to create a wrapper for the function, like: --- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC +++ servers/lloadd/libevent_support.c @@ -131,6 +131,20 @@ lload_libevent_cond_timedwait( return ldap_pvt_thread_cond_wait( cond, mutex ); } +/* + * libevent2 expects the thread id has a type of unsigned long. + */ +static unsigned long +lload_libevent_thread_self(void) +{ + unsigned long retval; + static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long), + "ldap_pvt_thread_t has to be smaller or equal to unsigned long"); + + retval = (unsigned long)ldap_pvt_thread_self(); + return (retval); +} + int lload_libevent_init( void ) { @@ -152,7 +166,7 @@ lload_libevent_init( void ) evthread_set_lock_callbacks( &cbs ); evthread_set_condition_callbacks( &cond_cbs ); - evthread_set_id_callback( ldap_pvt_thread_self ); + evthread_set_id_callback( lload_libevent_thread_self ); return 0; } Or, maybe the code should just use evthread_use_pthreads() instead? (It's not very clear to me why we have the ldap_pvt_thread_self wrapper). Another issue is that module_init.c is trying to assign config_generic_wrapper to bi->bi_config: module_init.c:154:19: error: incompatible function pointer types assigning to 'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char **)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct BackendDB *, const char *, int, int, char **)') [-Wincompatible-function-pointer-types] bi->bi_config = config_generic_wrapper; ^ ~~~~~~~~~~~~~~~~~~~~~~ For other backends, it's used as bi_db_config. It seems that I can set bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not clear to me what the original intention was... -- 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
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2023