openldap-bugs February 2025

openldap-bugs@openldap.org

1 participants
33 discussions

[Issue 10265] New: Make it possible to change olcBkLloadListen at runtime
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10265 Issue ID: 10265 Summary: Make it possible to change olcBkLloadListen at runtime 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: --- Currently, olcBkLloadListen changes only take effect on lloadd startup: - an added olcBkLloadListen should come online at the end of the modify operation - at the end of the modify operation a removed olcBkLloadListen will stop listening on the sockets associated with it, clients that connected over these are marked CLOSING - to facilitate replacing a value where URIs resolved sockets overlap, olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass Lloadd's startup was modelled upon slapd's, but the requirements have changed considerably when it was turned into a module. Sockets are acquired at module configuration time, which is much later than standalone/slapd's own startup and so the way the URLs are handled also needs to be reworked. This will resolve other related issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

19 Feb '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 15

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • d66062dc by Ondřej Kuzník at 2025-02-19T18:37:48+00:00 ITS#7249 Let backend_attribute know who's calling it • 5c734d2b by Ondřej Kuzník at 2025-02-19T18:37:53+00:00 ITS#7249 Disallow memberof-addcheck when memberof is global -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10279] New: add debug notice also to client tools
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10279 Issue ID: 10279 Summary: add debug notice also to client tools Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: rossi.f(a)inwind.it Target Milestone: --- Created attachment 1040 --> https://bugs.openldap.org/attachment.cgi?id=1040&action=edit openldap-2.6.4-debug-notice.patch The command line -d option, when used for debugging, does nothing if openldap was not compiled byth --enable-debug option. For the server part there is a notice to the user regarding this, I propose to add the same also to client tools. Here is attached the simple patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10307] New: Regression when searching for nonexistent entries and no access to DB
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10307 Issue ID: 10307 Summary: Regression when searching for nonexistent entries and no access to DB Product: OpenLDAP Version: 2.5.17 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: --- Patch incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10302] New: Double free of idcursor
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10302 Issue ID: 10302 Summary: Double free of idcursor Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: simon.rupf(a)lzlabs.com Target Milestone: --- Created attachment 1050 --> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit proposed patch, which was created from current master, but also applies to 2.6.6 While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP samples started causing a double free error at the end of the slapadd run. While I can't share the LDIF in question and it didn't consistently cause the issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and suggest the attached patch that resolves that error to re-occur. I validated the patch still applies to the current master branch of openldap, as well as to 2.6.6 on EL9 where we encountered this. The error originally observed was this (commands being run as ldap user): [...] rm -r /var/lib/ldap mkdir /var/lib/ldap slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. -#################### 100.00% eta none elapsed 03s spd 4.2 M/s Closing DB...double free or corruption (!prev) Under valgrind, the following trace could be observed: valgrind --vgdb=full --leak-check=full --show-leak-kinds=all --track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== Memcheck, a memory error detector ==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2 ==502== PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted. PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted. ==502== Invalid read of size 8 ==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764) ==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202) ==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152) ==502== by 0x1D8291: slapadd (slapadd.c:511) ==502== by 0x1348C6: main (main.c:540) ==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd ==502== at 0x4847B4C: free (vg_replace_malloc.c:989) ==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638) ==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640) ==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066) ==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069) ==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962) ==502== by 0x1D8440: slapadd (slapadd.c:502) ==502== by 0x1348C6: main (main.c:540) ==502== Block was alloc'd at ==502== at 0x484482F: malloc (vg_replace_malloc.c:446) ==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690) ==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707) ==502== by 0x1D8150: slapadd (slapadd.c:453) ==502== by 0x1348C6: main (main.c:540) [...] Please advise if I can provide any further diagnostics, while I can still relatively easily reproduce the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10290] New: Combination of syncrepl+rwm+syncprov frees the wrong modlist
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10290 Issue ID: 10290 Summary: Combination of syncrepl+rwm+syncprov frees the wrong modlist 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: --- An MPR setup with rwm enabled (regardless of configuration it seems) will crash with the provided modlist being freed twice. This is the sequence of events of what is stored in op->orm_modlist, allocated and freed by whom, replacing the actual pointers to make it easier to track: syncrepl_message_to_op: preparing a modify with 0xoriginal syncrepl_op_modify: old modlist 0xoriginal replacing with 0xsyncrepl_op_modify rwm_op_modify: old modlist 0xsyncrepl_op_modify replacing with 0xrwm_op_modify <modify happens> syncrepl_modify_cb: freeing 0xsyncrepl_op_modify, replacing with 0xoriginal (forgetting 0xrwm_op_modify) rwm_op_rollback: freeing 0xoriginal replacing with 0xsyncrepl_op_modify syncrepl_message_to_op: went in with 0xoriginal, got 0xsyncrepl_op_modify back syncrepl_message_to_op: freeing 0xsyncrepl_op_modify Not sure who is at fault: syncrepl_modify_cb is the one freeing the wrong modlist, but then if backover were to work with an actual "stack", running response callbacks in the opposite order from the request, things would have been ok too. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 7080] post read control in back-config
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7080 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26 (2.6.10): • 8d19c205 by Ondřej Kuzník at 2025-02-19T18:06:29+00:00 ITS#7080 Do not munge path twice • f328965d by Ondřej Kuzník at 2025-02-19T18:06:33+00:00 ITS#7080 Implement pre/postread for modrdn • c667f2ea by Ondřej Kuzník at 2025-02-19T18:15:58+00:00 ITS#7080 Do not reuse back-ldif's stack for controls -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10229 Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10288] New: autoca Attribute olcAutoCAserverClass
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10288 Issue ID: 10288 Summary: autoca Attribute olcAutoCAserverClass Product: OpenLDAP Version: 2.6.9 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- I try to add the autoca overlay with the following ldif: -------------- dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config objectClass: olcAutoCAConfig objectClass: olcOverlayConfig olcOverlay: autoca olcAutoCADays: 3652 olcAutoCAKeybits: 4096 olcAutoCAserverClass: ipHost olcAutoCAserverDays: 1826 olcAutoCAserverKeybits: 4096 olcAutoCAuserClass: person olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 4096 -------------- ldapadd gives me: adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcAutoCAserverClass> handler exited with 1 If I remove the attribute from my ldif, it works. What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look it up in the admin handbook but I could not find anything. I looked in the source code and found: ------------ { "serverClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf, "( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' " "DESC 'ObjectClass of server entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------ For me it looks the same as the attribute olcAutoCAuserclass. ------------- { "userClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf, "( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' " "DESC 'ObjectClass of user entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2025