openldap-bugs March 2025

openldap-bugs@openldap.org

1 participants
44 discussions

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

22 May '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 6

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

22 May '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 9

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

22 May '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 6

[Issue 10168] New: olcdbindex doesn't cleanup cleanly
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10168 Issue ID: 10168 Summary: olcdbindex doesn't cleanup cleanly 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: --- if you run the following modify against slapd (notice the olcDbMultival data is wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the olcDbIndex changes: dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: member eq olcDbIndex: memberof eq - add: olcDbMultival olcDbMultival: member,memberOf 5,15 - -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10299] New: slapacl -u segfaults on nonexistent user
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10299 Issue ID: 10299 Summary: slapacl -u segfaults on nonexistent user Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: ratness(a)gmail.com Target Milestone: --- Created attachment 1048 --> https://bugs.openldap.org/attachment.cgi?id=1048&action=edit config.ldif 2.6.9, symas-packaged RPMs, Rocky 9. In slapacl, a rootDN user is, as you'd expect, allowed to do anything: # /opt/symas/sbin/slapacl -D 'cn=Manager,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "cn=manager,dc=example,dc=com" write access to entry: ALLOWED But, a user given full-manage rights, segfaults: # /opt/symas/sbin/slapacl -D 'uid=direct,ou=users,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "uid=direct,ou=users,dc=example,dc=com" Segmentation fault (core dumped) Traceback: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 2893 flags |= env->me_flags & MDB_WRITEMAP; Missing separate debuginfos, use: dnf debuginfo-install glibc-2.34-60.el9.x86_64 libevent-2.1.12-6.el9.x86_64 sqlite-libs-3.34.1-6.el9_1.x86_64 (gdb) bt #0 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 #1 0x00007ffff71361a1 in mdb_opinfo_get (op=op@entry=0x7fffffffdce0, mdb=mdb@entry=0x7ffff7048010, rdonly=rdonly@entry=1, moip=moip@entry=0x7fffffffc410) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:793 #2 0x00007ffff7136459 in mdb_entry_get (op=0x7fffffffdce0, ndn=0x7fffffffc640, oc=0x5555557a4360, at=0x5555557c3560, rw=0, ent=0x7fffffffc4c8) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:620 #3 0x00005555555a77a0 in be_entry_get_rw (e=0x7fffffffc4c8, rw=0, at=0x5555557c3560, oc=0x5555557a4360, ndn=0x7fffffffc640, op=0x7fffffffdce0) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1438 #4 fe_acl_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=0x7fffffffc640, op_ndn=0x7fffffffde10, group_oc=0x5555557a4360, group_at=0x5555557c3560) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1494 #5 0x000055555559ec5c in backend_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=<optimized out>, op_ndn=<optimized out>, group_oc=<optimized out>, group_at=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1690 #6 0x00005555555bfbc2 in slap_acl_mask (access=ACL_WRITE, state=0x7fffffffc660, count=1, matches=0x7fffffffcab0, val=<optimized out>, desc=<optimized out>, e=0x7fffffffd910, op=0x7fffffffdce0, mask=<synthetic pointer>, prev=0x0, a=0x5555557c3970) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:1643 #7 slap_access_allowed (op=op@entry=0x7fffffffdce0, e=e@entry=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:288 #8 0x00005555555c1e2e in fe_access_allowed (op=0x7fffffffdce0, e=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=0x7fffffffd828) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:352 #9 0x00005555555b7c74 in access_allowed_mask (op=0x7fffffffdce0, e=0x7fffffffd910, desc=0x55555573d540, val=<optimized out>, access=ACL_WRITE, state=0x0, maskp=0x7fffffffd900) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:456 #10 0x0000555555620182 in slapacl (argc=<optimized out>, argv=0x7fffffffe398) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/slapacl.c:362 #11 0x000055555557658f in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/main.c:540 I could understand it if it was a case of "trying to verify cn/write and not knowing if the user was objectClass=person" but for entry/write I don't see any reason these should be different. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10312] New: olcSubordinate does not accept a 'false' keyword, contrary to documentation
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10312 Issue ID: 10312 Summary: olcSubordinate does not accept a 'false' keyword, contrary to documentation Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gray(a)nxg.name Target Milestone: --- The slapd-config(5) manpage documents the olcSubordinate keyword as olcSubordinate: [TRUE | FALSE | advertise] If, however, I try to create a database using olcSubordinate: false then slapadd objects with olcSubordinate: value #0: suffix "ou=foo,o=bar": subordinate must be "TRUE" or "advertise". (For the sake of completeness, it might be worth noting in the manpage that the (unsurprising) default is for a search of a superior database _not_ to be propagated to the subordinate one – ie, the presumed behaviour of olcSubordinate:false) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 22 May '25

22 May '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 11

[Issue 10140] New: Add microsecond timestamp format for local file logging
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10140 Issue ID: 10140 Summary: Add microsecond timestamp format for local file logging 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: gnoe(a)symas.com Target Milestone: --- Add microsecond-level timestamps to local file logging. Format is: "YYYY-mm-ddTHH:MM:SS.ffffffZ" The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Gregory Noe Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

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

22 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 10279] New: add debug notice also to client tools
by openldap-its＠openldap.org 22 May '25

22 May '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 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2025