openldap-bugs October 2021

openldap-bugs@openldap.org

1 participants
181 discussions

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

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 16

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 28

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9244 Bug ID: 9244 Summary: API calls blocking after async connect Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Created attachment 721 --> https://bugs.openldap.org/attachment.cgi?id=721&action=edit async connect test without TLS My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should not block. If the connection does not establish fast enough, the bind call is supposed to return LDAP_X_CONNECTING. (At least that's how I understand it, based on the original behaviour (circa 2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand, the man page does "Subsequent calls to library routines will poll for completion of the connect before performing further operations" which might be interpreted as meaning they would block...) In current releases it does block, as demonstrated by strace on Linux (latency added using 'tc qdisc'): [...] connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in progress) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "0\f\2\1\1a\7\n", 8) = 8 read(3, "\1\0\4\0\4\0", 6) = 6 write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned 0 (Success) ) = 42 [...] As discussed in IRC, I believe I bisected this down to commit ae6347bac, from bug 8022. The reasoning is sound, but ldap_int_open_connection does not actually return -2, only -1 or 0. The patch is simple enough, but I'm also looking at some later commits that were probably done to work around this, and might not be needed now (bug 8957, bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps, STARTTLS, not to mention back-meta/asyncmeta). I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page doesn't mention this specifically, and I don't see why it would be necessary... -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9220 Bug ID: 9220 Summary: Rewrite Bind and Exop result handling 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: --- Bind and Exop result handling needs a rewrite so it is no longer a special case for overlays. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9731 Issue ID: 9731 Summary: startup messages still go to syslog when logfile-only is on Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When setting logfile-only on, slapd still logs its startup message to syslog: Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021 05:12:17) $#012#011openldap This is useful information to have consolidated into the specified logfile. Note that: 617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting does make it to the logfile. However, it would be useful to have the build date and version in the specified logfile. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its＠openldap.org 11 Nov '25

11 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 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: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 33

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

08 Sep '25

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 17

[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org 26 Aug '25

26 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta… With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2021