openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
69 discussions

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 10259] New: Wrong RID sends when using syncrepl provider
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10259 Issue ID: 10259 Summary: Wrong RID sends when using syncrepl provider Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: florent.david(a)gmail.com Target Milestone: --- When using a custom syncrepl consumer bind to an OpenLDAP v2.6.8 provider and it quickly appears than this provider sends to our consumer a cookie with a Replica ID different from the original one. In the logs below, we clearly see a refreshAndPersist synchronization initialized whith a RID with value 606. After a while, on the same connection, OpenLDAP syncrepl provider sends a new cookie with RID=612 66f2ea7d.3b1f8427 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: got a persistent search with a cookie=rid=606,csn=20240924154708.334351Z#000000#000#000000 66f2ea7d.3b1fafc0 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_findbase: searching 66f2ea7d.3b20ca28 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: registered persistent search 66f2ea7d.3b20e5bf 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: no change, skipping log replay 66f2ea7d.3b20ed6a 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: nothing changed, finishing up initial search early 66f2ea7d.3b20f874 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_sendinfo: refreshDelete cookie= 66f2ea7d.3b229483 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_search_response: detaching op 66f2ed56.12f82965 0x7fa816dfe6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164822.305028Z#000000#000#000000 66f2ed56.12fa5399 0x7fa7f58fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164822.305028Z#000000#000#000000 66f2ed8d.053d71e3 0x7fa8165fd6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164917.069189Z#000000#000#000000 66f2ed8d.05405bb4 0x7fa7ed3fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164917.069189Z#000000#000#000000 Is it a normal behaviour ? Should consumer checks the Replica ID sends by OpenLDAP before storing it ? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 14 Oct '24

14 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9367 Issue ID: 9367 Summary: back-mdb: encryption support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to add encryption support to the back-mdb backend, depends on issue#9364 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

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 12

[Issue 10258] New: test050 failure: connection_close race?
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10258 Issue ID: 10258 Summary: test050 failure: connection_close race? 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: --- Created attachment 1032 --> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit tail of slapd log Running test050 repeatedly, the slapd managed to get itself into an apparent inconsistency in the connections structure. The logs suggest that there might be a race closing the connection. Unfortunately the sanitiser didn't initiate a core dump in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10234] New: syncrepl does not reset the retrynum
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10234 Issue ID: 10234 Summary: syncrepl does not reset the retrynum Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- ``` syncrepl retry="5 10 30 +" ``` When replication fails with the above settings, syncrepl retries "10 times at 5 second intervals". Then, the retry count should be reset on the next replication failure. In actual, it does not reset. The behavior is as follows: ``` (first time replication failure) do_syncrepl: rid=001 rc -1 retrying (9 retries left) do_syncrepl: rid=001 rc -1 retrying (8 retries left) (resume replication) (second time replication failure) do_syncrepl: rid=001 rc -1 retrying (7 retries left) do_syncrepl: rid=001 rc -1 retrying (6 retries left) ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10232] New: assert() at shutdown if a syncrepl session is in refresh
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10232 Issue ID: 10232 Summary: assert() at shutdown if a syncrepl session is in refresh 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 removing the last one, syncinfo_free() checks that there is no active refresh on the backend. This works if operating on olcSyncrepl values because refresh_finished is called where appropriate. However if we're shutting down, this is skipped to make sure we don't schedule a new task and that could lead to an assert failure if there indeed was a refresh in progress (the same probably applies when removing the DB). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10248] New: translucent + subordinate regression
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10248 Issue ID: 10248 Summary: translucent + subordinate regression Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mike(a)nolta.net Target Milestone: --- Created attachment 1027 --> https://bugs.openldap.org/attachment.cgi?id=1027&action=edit translucent + subordinate regression testcase, formatted for tests/data/regressions/ Hi, Attached please find a testcase for a regression we noticed in a translucent + subordinate slapd configuration. The test works in version 2.4.59, but fails in versions 2.5.5 and 2.6.8. In a nutshell, search results from the subordinate database aren't being returned, even though (judging by the logs) they appear to be found. Thanks, -Mike -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10249] New: slapo-nestgroup leak with non-nested groups
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10249 Issue ID: 10249 Summary: slapo-nestgroup leak with non-nested groups 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: --- Searching for a member= of a group when no nesting is in place will leak memory. It seems to stem from a few `gi.gi_numDNs` tests that should most likely be against `gi.gi_DNs` instead. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2024