openldap-bugs June 2026

openldap-bugs@openldap.org

1 participants
209 discussions

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9204 Bug ID: 9204 Summary: slapo-constraint allows anyone to apply Relax control Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- slapo-constraint doesn't limit who can use the Relax control, beyond the global limits applied by slapd. In practice, for many modifications this means any configured constraints are advisory only. In my opinion this should be considered a bug, in design if not implementation. I expect many admins would not read the man page closely enough to realize the behaviour does technically adhere to the letter of what's written there. Either slapd should require manage privileges for the Relax control globally, or slapo-constraint should perform a check for manage privilege itself, like slapo-unique does. Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4: > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Note that the user: > > - must have enough privileges to do it (manage) > > - must inform the DSA that intends to violate the constraint (by using > the control) but such privileges are currently not being required. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Issue 10308] New: Implement cn=monitor for back-asyncmeta
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10308 Issue ID: 10308 Summary: Implement cn=monitor for back-asyncmeta Product: OpenLDAP Version: unspecified 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: --- Currently back-asyncmeta has no cn=monitor capabilities. It will be useful to implement some, specifically to monitor targets and target connection states. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10494] New: require none still has no effect
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10494 Issue ID: 10494 Summary: require none still has no effect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Both frontend and DB requires are unconditionally ORed, contrary to what the documentation says. Probably a disconnect between ITS#4574 and ITS#5857 understanding of what should happen. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10499] New: Enable test-level tracking in CI
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10499 Issue ID: 10499 Summary: Enable test-level tracking in CI Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Gitlab supports parsing junit-style XML reports. We can emit something like this from our test suite and get a better idea how our tests perform/which test failed at a glance. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

07 Aug '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 6

[Issue 10465] New: accesslog_purge mdb scheduling is unfair
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10465 Issue ID: 10465 Summary: accesslog_purge mdb scheduling is unfair 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: --- On most systems, a running accesslog purge task on a back-mdb data will starve other modifications for oxygen: It issues deletes to the DB with a very narrow gap where it might be usefully preempted, on a multi-CPU systems it usually manages to reacquire the TXN mutex before another waiting thread can even wake up. Meanwhile a live modification has to issue a modification to the original DB, then get to the point where it waits to acquire a write TXN on the accesslog DB, all the while holding li_rmutex preventing any other modification from getting under way. So even one wins the mutex, another one is unlikely to do so straight away. This means that write latencies can and usually do shoot through the roof until the purge task finishes. If 1% of time is spent on write ops on average and an accesslog purge is scheduled to run every 30 mins, that is ~18 seconds of work for the purge task to remove those entries. On a busy system, write latencies of above 1 second (which this can easily spiral to) might be unacceptable, especially when ppolicy/lastbind etc. are configured. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9878] New: test043 failures in 2.5/2.6
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9878 Issue ID: 9878 Summary: test043 failures in 2.5/2.6 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: --- With test043 update for ITS#9823, we manage to introduce a scenario where the server is completely idle except for a runqueue change. This is partly identical with ITS#9642 and a similar approach would work. Except that changes our module facing ABI so might not be something we can backport. For the streams we can't, we might have to change the test to make the server not idle. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10073] New: database monitor | slapd fails to start when "database ldap" without suffix exists
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10073 Issue ID: 10073 Summary: database monitor | slapd fails to start when "database ldap" without suffix exists Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: cyusedfzfb(a)gmail.com Target Milestone: --- As requested on the mailinglist, I am filing an issue for this behaviour: Today setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. It would be nice if this error message could become a little bit more specific. :-) Also: we've had the "database ldap" without a suffix in production working for many years. Perhaps cn=Monitor should be able to deal with that config as well..? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10084] New: Move away from DIGEST-MD5 as a default in the test suite
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10084 Issue ID: 10084 Summary: Move away from DIGEST-MD5 as a default in the test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2 onwards. As such we should update our defaults in a couple of our test scripts for master/2.7 at least. Are SCRAM mechanisms the go-to these days? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10415] New: Allow limiting the buffers for data pending to be sent to client
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10415 Issue ID: 10415 Summary: Allow limiting the buffers for data pending to be sent to client 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: --- In many scenarios it is more useful to limit the amount of data we buffer to be written to the client's socket even if it means that sometimes a connection might have to be dropped abruptly to enforce this. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

← Newer
1
...
6
7
8
9
10
11
12
...
21
Older →

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 June 2026