openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
129 discussions

[Issue 10160] New: Add negset and negurl for slapo-constraint
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10160 Issue ID: 10160 Summary: Add negset and negurl for slapo-constraint 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: manu(a)netbsd.org Target Milestone: --- Created attachment 1003 --> https://bugs.openldap.org/attachment.cgi?id=1003&action=edit Add negset and negurl for slapo-constraint Add negset and negurl constraints for slapo-constraint. THe two new types are logical not of set and url. They will fire a constraint violation if the set or LDAP URL query is non empty. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests 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: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10250] New: syncrepl_diff_entry assumes attributes come in the same order
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=10250 Issue ID: 10250 Summary: syncrepl_diff_entry assumes attributes come in the same order 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: --- When trying to diff an entry, syncrepl_diff_entry explicitly assumes attribute come in the same order. That's not always the case and could cause it to report a spurious rewrite of the attribute. Normally this is ok, unless the rewrite itself (not) occurring has other side-effects, when it could cause issues. (e.g. a DB with memberof inconsistencies being mysteriously repaired in some scenarios, which is how it was found). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9224 Bug ID: 9224 Summary: Add support for PREPARE/2-phase commit Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In LMDB, add support for PREPARE/2-phase commits -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 10 Feb '26

10 Feb '26

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 12

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

10 Feb '26

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 21

[Issue 10132] New: manage syncrepl as a cn=config entry
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry 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: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 12 Jan '26

12 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=9884 Issue ID: 9884 Summary: Document "set" patterns in ACLs Product: OpenLDAP Version: unspecified 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: --- The slapd.access(5) man page has this exceptionally unhelpful line where sets are concerned: "The statement set=<pattern> is undocumented yet." Even if it is an experimental feature, it should still be documented on how it is meant to operate. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2024