openldap-bugs

openldap-bugs@openldap.org

1 participants
21362 discussions

[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10424 Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: {0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry. Would I like to replicate, says, 'cn=config' with another syncrepl directive like: olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case). I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: commit 0347718de33ee4e3d0c3570166052c362da6080e Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Apr 7 16:23:23 2026 +0100 ITS#10476 Escape asserted value before pasting into filter RE26: commit 2028cb473609bcdd5cfe71a888586c03d0eb93db Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Apr 7 16:23:23 2026 +0100 ITS#10476 Escape asserted value before pasting into filter -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10518] New: Every write transaction leaks a mutex on Windows
by openldap-its＠openldap.org 09 Jun '26

09 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10518 Issue ID: 10518 Summary: Every write transaction leaks a mutex on Windows Product: LMDB Version: unspecified Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: bhargavabhat(a)gmail.com Target Milestone: --- Created attachment 1152 --> https://bugs.openldap.org/attachment.cgi?id=1152&action=edit Create and use the mutex for the duration of the env I see that on master3 branch, every write transaction leaks a mutex. LMDB creates a new mutex on every non-read-only transaction in `mdb_txn_renew0`. In `mdb_txn_end`, when the write transaction finishes, it sets `mode` to 0 and unlocks it. ``` if (!txn->mt_parent) { env->me_txn = NULL; mode = 0; if (env->me_txns) UNLOCK_MUTEX(env->me_wmutex); } ``` Later, it does this. ``` if (mode & MDB_END_FREE) { if (!F_ISSET(txn->mt_flags, MDB_TXN_RDONLY)) pthread_mutex_destroy(&txn->mt_child_mutex); // never reached free(txn); } ``` So we just don't close the mutex. It's probably not a big deal on non-Windows platforms, but on Windows, the number of handles owned by the process keeps increasing which limits the total number of write transactions we can do in the lifetime of the process. I didn't really understand why we need to create a mutex on every non-read-only transaction. Can we just tie the lifetime of the mutex to the environment instead of the transaction? I'm attaching a patch which tries to fix it. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=8901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 23c07757 by Howard Chu at 2026-06-04T18:02:30+00:00 ITS#8901 ldap_pvt_thread: add _detach() support • 5be6295e by Howard Chu at 2026-06-04T18:02:30+00:00 ITS#8901 tpool: use joinable threads instead of detached RE27: • 2fa6d246 by Howard Chu at 2026-06-08T19:44:05+00:00 ITS#8901 ldap_pvt_thread: add _detach() support • fb41f6a1 by Howard Chu at 2026-06-08T19:44:10+00:00 ITS#8901 tpool: use joinable threads instead of detached -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

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

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

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

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=6198 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • e922f9f1 by Ondřej Kuzník at 2026-06-08T01:31:08+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options RE27: • 0e10c595 by Ondřej Kuzník at 2026-06-08T18:07:59+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10517] New: mbedTLS doesn't verify certificate in reqcert try mode
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10517 Issue ID: 10517 Summary: mbedTLS doesn't verify certificate in reqcert try mode Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When setting the authmode to OPTIONAL, mbedTLS documentation[0] says that it's the user's responsibility to check the verification result if they care. `reqcert try` does care, but mbedtls_ssl_get_verify_result is never called in that case and so an invalid cert is not detected (easy to test by changing line 204 in test067). [0]. https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#a569528… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs