- openldap-bugs - openldap.org

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 24 Mar '24

24 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #34 from mdufour(a)audiokinetic.com --- Thanks to the test application, I was able to identify a key missing step in my description: process2 creates a named database (under a different name) after dropping the initial one. I can reproduce the crash by inserting the following lines @ 104: E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, "id2", MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #33 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #31) > I am able to reproduce the crash in a scenario with two processes accessing > the same LMDB file, where: > > - process1 opens a named database. > - process2 drops this named database. > - process1 writes to the initial named database (using the dbi it was > holding on to) -> this is where we crash. > > It seems that mdb_page_search returns MDB_NOTFOUND because the named > database is gone, leaving mc->mc_pg[0] NULL. Thanks for that info. Unfortunately I still can't reproduce that crash. I've attached the test code I wrote based on your info. It forks off a child to do the process2 actions. You must press RETURN when you're ready for process 1 to proceed. I just get more MDB_NOTFOUND results when process1 tries to write again. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #32 from Howard Chu <hyc(a)openldap.org> --- Created attachment 1015 --> https://bugs.openldap.org/attachment.cgi?id=1015&action=edit Attempted reproduction -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 18 Mar '24

18 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #31 from mdufour(a)audiokinetic.com --- I am able to reproduce the crash in a scenario with two processes accessing the same LMDB file, where: - process1 opens a named database. - process2 drops this named database. - process1 writes to the initial named database (using the dbi it was holding on to) -> this is where we crash. It seems that mdb_page_search returns MDB_NOTFOUND because the named database is gone, leaving mc->mc_pg[0] NULL. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 16 Mar '24

16 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #30 from mdufour(a)audiokinetic.com --- We're on revision ce200dca of the main openldap repo from Aug 27, 2023. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #29 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #28) > Apologies, in the last message, the provide line of code is indeed 7998, the > crash location (and not 8183 as written). It is slightly different from the > official mdb.c due to some unrelated local changes earlier in the file. You didn't specify which version of LMDB you're using. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #28 from mdufour(a)audiokinetic.com --- Apologies, in the last message, the provide line of code is indeed 7998, the crash location (and not 8183 as written). It is slightly different from the official mdb.c due to some unrelated local changes earlier in the file. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #27 from mdufour(a)audiokinetic.com --- We are also seeing rare instances of this crash since we released a version of our product which uses LMDB. Specifically, call stack is: mdb_cursor_put(MDB_cursor * mc, MDB_val * key, MDB_val * data, unsigned int flags) Line 7998 mdb_put(MDB_txn * txn, unsigned int dbi, MDB_val * key, MDB_val * data, unsigned int flags) Line 10107 where line 8183 is nsize = IS_LEAF2(mc->mc_pg[mc->mc_top]) ? key->mv_size : mdb_leaf_size(env, key, rdata); and mc->mc_top == 0 mc->mc_pg[0] == NULL rc == -30798 Although we do not have a reproduction case, we do have a full crash dump with heap of an unoptimized debug build of our application. There is no evidence of stack corruption (in fact, mc->mc_pg[1] is still 0xcccccccccccccccc as per the msvc run-time check initialization). Unfortunately we do not have the matching LMDB file. Anything we can provide to help narrow down the issue? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10187] New: I need to build an LDAP server from this image that runs as non-root
by openldap-its＠openldap.org 12 Mar '24

12 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10187 Issue ID: 10187 Summary: I need to build an LDAP server from this image that runs as non-root Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: deepakganiger4(a)gmail.com Target Milestone: --- I need to build an LDAP server from this image that runs as non-root. Is there a way to do this? I've tried creating a user with root privileges and then running as this user, but the server fails to start. Our Kubernetes environment requires that we run all pods as non-root -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10184] New: slapo-translucent
by openldap-its＠openldap.org 05 Mar '24

05 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10184 Issue ID: 10184 Summary: slapo-translucent Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: marco.esposito(a)gmail.com Target Milestone: --- I am currently experiencing an issue with an OpenLDAP instance configured with the slapo-translucent overlay. After performing an ldapmodify: # ldapmodify -x -D cn=Manager,dc=example,dc=com -W -H ldap:/// <<EOF dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF LDAP queries requesting only translucent local attributes do not return results unless both the remote and local attributes are included in the filter. Here is an example illustrating the behavior: Query with both remote and local attributes in the filter after ldapmodify (works correctly): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uid uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uid uidNumber # # user, People, example.com dn: uid=user,ou=People,dc=example,dc=com uidNumber: 99 uid: user # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Query with only local attributes in the filter after ldapmodify (does not return results): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 While attempting to debug the issue, I believe the problem may be related to the code in lines 928 - 940 of the file overlays/translucent.c: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over… Specifically, I suspect that the issue may be related to the conditions within the 'if' statement. I have carefully reviewed the slapd instance configuration and overlay settings, but I have not been able to identify the root cause. Any assistance or advice on resolving this issue would be greatly appreciated. Thank you for your time and support. Best regards, Marco -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10181] New: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake
by openldap-its＠openldap.org 22 Feb '24

22 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10181 Issue ID: 10181 Summary: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- The list of LDAP_OPT_X_TLS_* constants does not include anything for setting allowed curves/groups (SSL_CTX_set1_groups_list()) or signature algorithms (SSL_CTX_set1_client_sigalgs_list(), SSL_CTX_set1_sigalgs_list()) for TLS handshakes. Support for OpenSSL's SSL_CONF_cmd() et al. API would also be a nice addition. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10136] New: Sync replication causing glue entries.
by openldap-its＠openldap.org 16 Feb '24

16 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10136 Issue ID: 10136 Summary: Sync replication causing glue entries. Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mbalakri(a)opentext.com Target Milestone: --- Created attachment 991 --> https://bugs.openldap.org/attachment.cgi?id=991&action=edit Node1 and Nod2 sync replication logs We have configured mirror mode replication with two nodes. Node1 syncrepl {0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk" Node2 syncrepl {0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk" olcMultiProvider is ON. Now when records are inserted into node1, it is replicating to node2 but after sometime glue entries are created in node2 and from then onwards replication is not working. Attached the sync logs from both the nodes. The below two entries are in glue state and not recovering from this state. cn=Method Set CAPackage,cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net Any clue on what is going wrong here? Is this due to the 'retry' configuration? -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[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 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=7400 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ab55c7fd by Howard Chu at 2024-02-06T01:22:58+00:00 ITS#7400 memberof: note consumers must use exattr RE26: • 6b81fca5 by Howard Chu at 2024-02-15T17:56:24+00:00 ITS#7400 memberof: note consumers must use exattr -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 10178] New: deltaMPR conflict resolution issues
by openldap-its＠openldap.org 15 Feb '24

15 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10178 Issue ID: 10178 Summary: deltaMPR conflict resolution issues Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review, replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Created attachment 1013 --> https://bugs.openldap.org/attachment.cgi?id=1013&action=edit Illustation environment When a data conflict is introduced (multiple writes to the same entry in different providers), there are three different strategies and they are incompatible, see the attached test script for an example. 1. DeltaMPR providers have access to accesslog and reinterpret the operation as if it happened in CSN order 2. Delta consumers (olcMultiProvider: FALSE) have the above code disabled so have to accept the accesslog entry as-is, but the entry represents the original, not reinterpreted write 3. plain syncrepl - just ignores the out of order version This *cannot* (and does not) mesh well as at least 1. and 3. are always around in deltaMPR. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10174] New: Fails to authenticate user against Active directory if double space is present in the user's DN in AD
by openldap-its＠openldap.org 12 Feb '24

12 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10174 Issue ID: 10174 Summary: Fails to authenticate user against Active directory if double space is present in the user's DN in AD Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: codedriller(a)gmail.com Target Milestone: --- In a proxy configuration when using Meta backend to connect to Active directory, an AD user can't be authenticated through OpenLDAP if there is a double space somewhere in his or her Active directory's DN, for example: CN=John Doe,OU=IT Department,DC=example,DC=com. I'm no LDAP expert but I suppose that the reason for this is that after slapd does initial samAccountName search, it normalizes the found DN including removing a double space according to RFC 2252 paragraph 8.1., then the bind attempt is made using the normalized DN and it fails, because Active directory has no built-in double space removal (or it can be disabled somehow), and the normalized DN does not match the real DN in Active directory. Excuse me if my usage of LDAP terms is not accurate. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 5625] memberOf search ACLs
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.8 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 01 Feb '24

01 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|1 |0 Status|VERIFIED |UNCONFIRMED Resolution|WONTFIX |--- --- Comment #19 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Looking to fix memberOf rather than deprecate, re-opening -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 31 Jan '24

31 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7249 --- Comment #18 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Looking at the Arch patch, might be related to ITS#10135? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6509] slapo-memberof follow cascading group membership
by openldap-its＠openldap.org 31 Jan '24

31 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=6509 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10161 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs