openldap-bugs September 2023

openldap-bugs@openldap.org

1 participants
161 discussions

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

05 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 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 05 Dec '25

05 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 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 26 Nov '25

26 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 12 Nov '25

12 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 05 Nov '25

05 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 10092] New: Local logging doesn't build on Windows
by openldap-its＠openldap.org 20 Aug '25

20 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=10092 Issue ID: 10092 Summary: Local logging doesn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- slapd/logging.c uses writev() to write a prefix and the log message together in one call. This feature doesn't exist on Windows. The closest equivalent, WriteFileGather, only works on page sized and aligned writes. On Windows the only way to write as desired is to copy the message into a new buffer first. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9849] New: Update website to support LTS and Feature releases
by openldap-its＠openldap.org 16 Jul '25

16 Jul '25

https://bugs.openldap.org/show_bug.cgi?id=9849 Issue ID: 9849 Summary: Update website to support LTS and Feature releases Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mnormann(a)symas.com Target Milestone: --- Modify .wlmrc variable names and website content to handle both Feature Release and Long Term Support release. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10020 Issue ID: 10020 Summary: dynlist's @groupOfUniqueNames is considered only for the first configuration line Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- If we consider the following configuration of dynlist: {0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames The {0} entry will correctly populate the memberOf relatively to static group membership. The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration - or - remove @groupOfUniqueNames part from this configuration line, then both dynamic and static entries will be populated correctly for {1}. So the effects are as follows on some user entry: if both {0} and {1} are present - {1} produced only dynamic groups: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl If only {1} is present - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl For completness - if only {0} is present: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl I would expect this behavior to be correct for the first case - {0} and {1}. memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 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: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10056] New: test069-delta-multiprovider-starttls failures on static builds
by openldap-its＠openldap.org 08 Feb '25

08 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10056 Issue ID: 10056 Summary: test069-delta-multiprovider-starttls failures on static builds Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kaction(a)disroot.org Target Milestone: --- Hello. I am getting following test error when trying to build `openldap` statically: ``` [nix-shell:/tmp/openldap-static/openldap-2.6.4/tests]$ ./run test069-delta-multiprovider-starttls Cleaning up test run directory leftover from previous run. Running ./scripts/test069-delta-multiprovider-starttls for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Waiting 5 seconds for slapd to start... Using ldapadd for context on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Waiting 5 seconds for slapd to start... Using ldapadd to populate server 1... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Using ldapadd to populate server 2... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Breaking replication between server 1 and 2... Using ldapmodify to force conflicts between server 1 and 2... Restoring replication between server 1 and 2... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... test failed - server 1 and server 2 databases differ (561) ``` I added line number (561) into error message to pinpoint it more precisely. And here is difference between databases: ``` --- /tmp/openldap-static/openldap-2.6.4/tests/testrun/server1.flt 2023-05-23 22:53:51.000965129 -0400 +++ /tmp/openldap-static/openldap-2.6.4/tests/testrun/server2.flt 2023-05-23 22:53:51.005965136 -0400 @@ -289,13 +289,10 @@ userPassword:: amFq dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com -carLicense: 123-XYZ cn: James A Jones 2 cn: James Jones cn: Jim Jones -description: Amazing description: Bizarre -description: Mindboggling description: Stupendous employeeNumber: 64 employeeType: deadwood @@ -307,7 +304,7 @@ pager: +1 313 555 3923 postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -sn: Surname +sn: Jones telephoneNumber: +1 313 555 0895 title: Mad Cow Researcher, UM Alumni Association uid: jaj ``` Suggestions on what more information I can provide are welcome. You can also try to build `pkgsStatic.openldap` in this nixpkgs [commit](f9e32f61282275eb5fa9064e08bbd0a92d1187de) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

← Newer
1
...
7
8
9
10
11
12
13
...
17
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 September 2023