March 2025 - openldap-bugs

[Issue 10301] New: Use assertion control in lastbind chaining
by openldap-its＠openldap.org 12 Jun '25

12 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10301 Issue ID: 10301 Summary: Use assertion control in lastbind chaining 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: --- Take a setup with a bunch of consumers tracking lastbind information and replicating this back from the provider. If a client sends a lot of successful binds to it in a very short window, the changes might not have a chance to replicate down so each of these binds has to trigger a new modification to be forwarded. This results in a lot of DB churn and replication traffic that is actually meaningless (the pwdLastChange values before and after each of the mods will be the same). We probably can't avoid having to send something, but the change we send could have an assertion control attached that lets the provider skip it if pwdLastChange>=new_value, saving on all of the additional processing (and additional useless replication traffic). -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10303] New: Web site still presents the 2.5 version as LTS
by openldap-its＠openldap.org 27 May '25

27 May '25

https://bugs.openldap.org/show_bug.cgi?id=10303 Issue ID: 10303 Summary: Web site still presents the 2.5 version as LTS Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- The OpenLDAP web site still indicates that the OpenLDAP 2.5 version is the LTS, despite a mail announced on August 10, 2024 that starting from January 2025 teh 2.6 branch will be the LTS. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

23 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 23 May '25

23 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 23 May '25

23 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 23 May '25

23 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 23 May '25

23 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 23 May '25

23 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 23 May '25

23 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 23 May '25

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

23 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

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

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

[Issue 10309] New: Handle potential null pointers returned by ber_strdup
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10309 Issue ID: 10309 Summary: Handle potential null pointers returned by ber_strdup 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: safecoding233(a)gmail.com Target Milestone: --- Created attachment 1052 --> https://bugs.openldap.org/attachment.cgi?id=1052&action=edit fix patch I added two null pointer checks for pointers returned by ber_strdup. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10320] New: sigsegv in autogroup
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10320 Issue ID: 10320 Summary: sigsegv in autogroup Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sergej+openldap(a)p5n.pp.ru Target Milestone: --- slapd crashes in autogroup overlay on group modification I have few coredumps and can provide more information. This fails on 0x23 address, it may differs but it looks like f->f_un.f_un_complex is not ended with NULL sometimes. Modified group here is not autogroup, just groupOfUniqueNames. Operation is adding uniqueMember. Distro: Archlinux Overlay config: overlay autogroup autogroup-attrset labeledURIObject labeledURI uniqueMember autogroup-memberof-ad memberOf Stack: #0 0x00007e77bf511d7c in autogroup_memberOf_filter (f=f@entry=0x6f2c6d6165742d70, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1532 #1 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x6f2c6d6165742d70, f@entry=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1537 #2 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=0x5ac9490c2190) at autogroup.c:1537 #3 0x00007e77bf512538 in autogroup_modify_entry (op=<optimized out>, rs=0x7e7665cf9910) at autogroup.c:1606 #4 0x00005ac946faf432 in overlay_op_walk () #5 0x00005ac946faf5f2 in ?? () #6 0x00005ac946f494cf in fe_op_modify () #7 0x00005ac946f4b623 in do_modify () #8 0x00005ac946f304d7 in ?? () #9 0x00005ac946f30f4b in ?? () #10 0x00007e77c04756e1 in ldap_int_thread_pool_wrapper (xpool=0x5ac949016bc0) at tpool.c:1059 #11 0x00007e77bfe4b70a in start_thread (arg=<optimized out>) at pthread_create.c:448 #12 0x00007e77bfecfaac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (gdb) p *f Cannot access memory at address 0x23 (gdb) up #1 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x23, f@entry=0x55d1c45b6310, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) up #2 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x55d1c45b6310, f@entry=0x55d1c45b6670, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) p *f->f_un.f_un_complex $5 = {f_choice = 124232868587560, f_un = {f_un_result = 939550768, f_un_desc = 0x70fd38006830, f_un_ava = 0x70fd38006830, f_un_ssa = 0x70fd38006830, f_un_mra = 0x70fd38006830, f_un_complex = 0x70fd38006830}, f_next = 0x23} f_next is 0x23 which is bad address -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10226] New: [PATCH] ldap.conf: some remarks and editorial fixes for this man page
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10226 Issue ID: 10226 Summary: [PATCH] ldap.conf: some remarks and editorial fixes for this man page Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bjarniig(a)vortex.is Target Milestone: --- Created attachment 1020 --> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit Remarks and editotiral fixes for the manual ldap.conf.5 Version 2.6.8 is not named on the webpage when entering an issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10270] New: Issues with pcache when refresh/persistPcache used
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10270 Issue ID: 10270 Summary: Issues with pcache when refresh/persistPcache used Product: OpenLDAP Version: 2.5.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Greetings, OpenLDAP-folk. We've been running with the pcache overlay in 2.5.18 with both query refresh and pcachePersist for a bit and have observed some oddities: 1.) Negative queries don't get refreshed 2.) Queries don't seem to be persisted These behaviors are all exhibited from the current git version as well - code/patches below for clarity of communication: Thanks! Andy commit c0b4fe92c8df746c0e6a777f93f1687135114eb9 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:43:47 2024 -0400 negative cache entries are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 9ef78fd6bf43..9fd72e6d7261 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -802,7 +802,11 @@ url2query( goto error; } - cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + if (BER_BVISNULL( &uuid )) { + cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 ); + } else { + cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + } if ( cq != NULL ) { cq->expiry_time = expiry_time; cq->refresh_time = refresh_time; commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:38:36 2024 -0400 queries with ttr/x-refresh are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 40c1f9673776..9ef78fd6bf43 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -749,7 +749,7 @@ url2query( } } - if ( got != GOT_ALL ) { + if ( (got & GOT_ALL) != GOT_ALL) { rc = 1; goto error; } commit c7e52c90192a43876d40b9776a58db951d27937c Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:37:13 2024 -0400 ttr was not being applied to negatively cached entries diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 1d6e4ba4edcf..40c1f9673776 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -1580,6 +1580,8 @@ add_query( case PC_NEGATIVE: ttl = templ->negttl; + if ( templ->ttr ) + ttr = now + templ->ttr; break; case PC_SIZELIMIT: -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[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 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 20 May '25

20 May '25

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10297] New: LDAP initialization does unnecessary resolution of hostname
by openldap-its＠openldap.org 14 May '25

14 May '25

https://bugs.openldap.org/show_bug.cgi?id=10297 Issue ID: 10297 Summary: LDAP initialization does unnecessary resolution of hostname 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: simon.pichugin(a)gmail.com Target Milestone: --- curl --version does try to resolve local hostname, which is usually stored in $HOSTNAME variable. It seems it does that for no good reason. It does not matter whether machine hostname is already FQDN or not, it always try it unconditionally by calling getaddrinfo(3). Every usage of dnf tries to resolve hostname. That is then supressed by myhostname on Fedora, which returns non-helping response. Possibly, the hostname should be fetched from actual network responses. Seen with: openldap-2.6.8-5.fc41.x86_64 Reproducible: Always Steps to Reproduce: 1. dnf install gdb curl 2. gdb --args curl --version 3. (gdb) break getaddrinfo 4. (gdb) run Actual Results: getaddrinfo is called with current hostname, stored into ldap_int_hostname variable. That is used only when ldap client has not configured target server. But this hostname seems fetched always. Expected Results: No network activity happens, unless something is actually requested. This is not the case. Suggestion is to make it lazy initialized. It should be tried only when necessary. This seems to be useful when tlso_session_chkhost in libraries/libldap/tls_o.c is used. It should initialize hostname only once conditions to use it happens. There is a fallback anyway. It should query FQDN only when name_in contains unusable response. Related: https://github.com/systemd/systemd/issues/34897 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10321] New: slapd garbles userCertificate hex code
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10321 Issue ID: 10321 Summary: slapd garbles userCertificate hex code Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jnabasny(a)gmail.com Target Milestone: --- I discovered an issue with how slapd handles hex encoded userCertificate;binary values while testing identical setups between FreeIPA and OpenLDAP. It seems to partially decode the hex, causing any search to fail. This was discovered when using SSSD, but is reproducible with ldapsearch. Essentially, you run a query like this using the hex encoded value of the certificate: ldapsearch -H ldap://10.10.0.94 -D cn=admin,dc=nabasny,dc=com -b "dc=nabasny,dc=com" -W '(&(userCertificate;binary=\30\82\04\85\30\82\02\ed\a0\03\02\01\02\02\01\0d\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\30\37\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1e\17\0d\32\35\30\33\32\30\31\35\34\35\32\36\5a\17\0d\32\37\30\33\32\31\31\35\34\35\32\36\5a\30\26\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\0d\30\0b\06\03\55\04\03\0c\04\6a\61\6b\65\30\82\01\22\30\0d\06\09\2a\86\48\86\f7\0d\01\01\01\05\00\03\82\01\0f\00\30\82\01\0a\02\82\01\01\00\b9\b2\3b\be\d1\20\bd\f2\ba\69\e6\b6\e5\2d\13\b0\77\a6\59\69\50\76\4c\07\71\ce\ee\8f\41\ef\04\20\1b\8e\a5\f7\8a\96\0d\f1\89\a5\84\cd\2f\be\ff\9c\2a\b2\bf\99\20\ca\ae\fc\a2\16\df\40\5b\d4\5e\7b\51\a5\b0\dd\bc\e9\c4\b1\e7\89\7c\25\f2\4b\b0\08\09\bd\60\58\c1\8f\af\fb\2a\5e\90\69\37\27\40\61\62\bb\7a\b8\76\18\11\96\2e\45\54\26\b0\c7\ec\92\3c\72\90\52\1a\44\0f\69\5c\b4\f1\98\53\4e\15\86\33\1a\81\ee\70\63\ae\e4\c7\32\7f\92\14\71\9d\58\c0\7d\a1\20\dc\f5\f6\47\29\45\56\bd\a2\dd\eb\4a\17\f2\2a\72\6f\fd\0f\a3\7e\a0\96\de\02\f3\b2\d9\ac\fc\af\38\c9\7a\21\c3\1b\19\4c\bc\d8\11\48\22\cf\18\ec\17\85\51\e9\51\22\49\aa\89\1a\73\2b\8d\40\e9\a9\3a\dd\e8\6e\9b\27\45\09\fd\a4\88\f5\7c\4e\96\b7\82\cd\f6\e2\1e\08\53\38\af\f9\4d\55\9c\79\0f\32\d8\bb\85\83\08\c0\b9\f3\39\7f\b9\7b\a9\02\03\01\00\01\a3\82\01\2b\30\82\01\27\30\1f\06\03\55\1d\23\04\18\30\16\80\14\0d\6b\b6\82\13\0c\a2\9d\91\01\40\e8\59\d6\2b\ec\87\1a\f0\36\30\3e\06\08\2b\06\01\05\05\07\01\01\04\32\30\30\30\2e\06\08\2b\06\01\05\05\07\30\01\86\22\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\63\61\2f\6f\63\73\70\30\0e\06\03\55\1d\0f\01\01\ff\04\04\03\02\04\f0\30\1c\06\03\55\1d\25\04\15\30\13\06\08\2b\06\01\05\05\07\03\01\06\07\2b\06\01\05\02\03\05\30\77\06\03\55\1d\1f\04\70\30\6e\30\6c\a0\34\a0\32\86\30\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\69\70\61\2f\63\72\6c\2f\4d\61\73\74\65\72\43\52\4c\2e\62\69\6e\a2\34\a4\32\30\30\31\0e\30\0c\06\03\55\04\0a\0c\05\69\70\61\63\61\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1d\06\03\55\1d\0e\04\16\04\14\e8\11\4b\36\86\c9\7c\a2\d7\4e\ff\7c\13\89\2b\38\8d\c4\ec\32\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\03\82\01\81\00\58\af\2b\7e\fd\05\b9\46\8a\c7\b9\e4\96\42\47\2d\8f\17\01\8e\58\30\95\9c\be\e7\2d\a8\22\64\5e\fd\f5\ec\46\97\2d\88\bc\06\b0\e7\a3\77\a3\d0\b6\da\01\4f\73\f4\3d\c9\47\49\e2\d0\a0\e8\bd\a9\62\fd\6c\de\81\32\9a\33\d5\58\57\d8\c9\47\54\78\fa\69\20\49\11\c9\dc\4f\f4\bc\37\63\28\6a\fd\e2\f7\4b\0f\44\26\90\6c\22\c9\b8\ff\9a\36\05\a3\24\3c\58\73\6f\4b\17\2d\e3\22\30\aa\34\4e\2f\36\24\94\6a\24\9b\bf\ac\e5\23\33\f6\3f\cf\c7\dd\38\91\85\63\c0\61\55\5f\de\2b\e6\3d\13\4f\8c\6a\6a\1e\3b\0e\4a\8c\e9\c3\46\ef\02\bb\63\b7\09\9f\d8\5c\67\4c\c6\40\8f\1e\7e\c8\f0\89\4c\8f\f8\24\63\42\31\f9\5d\5b\2d\cb\78\c3\94\5f\3e\ca\b8\7b\68\9a\6a\09\0c\22\bd\da\39\9f\b7\0f\4f\20\a9\1a\de\d7\8a\31\af\a3\ac\14\d1\ba\90\b8\22\56\31\b1\52\78\73\6f\36\05\88\0b\56\31\fd\55\89\7d\55\8b\01\1d\58\0c\75\03\bd\7c\7b\05\c7\86\15\90\0c\f4\c6\91\d3\f6\73\e9\8f\1f\25\88\32\b2\cb\53\db\91\e4\8b\28\a1\22\7a\38\ac\f5\8b\32\51\d4\9e\d6\e1\15\0d\fb\8f\60\09\e5\0c\dd\d4\19\fe\f7\44\cd\ac\ff\82\94\16\f5\7d\19\57\30\79\96\4b\7b\61\d0\b8\c3\0c\1c\2f\89\7e\01\5e\a0\95\9a\aa\d3\e2\6d\d5\fa\2e\e8\57\5a\b3\45\23\17\40\c9\d3\92\9e\11\cc\c4\31\f2\e5\94\e3\8f\5e\d9\51\92\cd\46\77\33\c8\4b\50\84\73)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))' And slapd logs the query as: Mar 20 19:54:01 ldap slapd[457]: conn=1058 op=3 SRCH base="ou=people,dc=nabasny,dc=com" scope=2 deref=0 filter="(&(?userCertificate;binary=0\82\04\850\82\02\ED\A0\03\02\01\02\02\01\0D0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00071\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\1E0\1C\06\03U\04\03\0C\15Certificate Authority0\1E\17\0D250320154526Z\17\0D270321154526Z0&1\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\0D0\0B\06\03U\04\03\0C\04jake0\82\01"0\0D\06\09\2A\86H\86\F7\0D\01\01\01\05\00\03\82\01\0F\000\82\01\0A\02\82\01\01\00\B9\B2;\BE\D1 \BD\F2\BAi\E6\B6\E5-\13\B0w\A6YiPvL\07q\CE\EE\8FA\EF\04 \1B\8E\A5\F7\8A\96\0D\F1\89\A5\84\CD/\BE\FF\9C\2A\B2\BF\99 \CA\AE\FC\A2\16\DF@[\D4^{Q\A5\B0\DD\BC\E9\C4\B1\E7\89|%\F2K\B0\08\09\BD`X\C1\8F\AF\FB\2A^\90i7'@ab\BBz\B8v\18\11\96.ET&\B0\C7\EC\92<r\90R\1AD\0Fi\5C\B4\F1\98SN\15\863\1A\81\EEpc\AE\E4\C72\7F\92\14q\9DX\C0}\A1 \DC\F5\F6G\29EV\BD\A2\DD\EBJ\17\F2\2Aro\FD\0F\A3~\A0\96\DE\02\F3\B2\D9\AC\FC\AF8\C9z!\C3\1B\19L\BC\D8\11H"\CF\18\EC\17\85Q\E9Q"I\AA\89\1As+\8D@\E9\A9:\DD\E8n\9B'E\09\FD\A4\88\F5|N\96\B7\82\CD\F6\E2\1E\08S8\AF\F9MU\9Cy\0F2\D8\BB\85\83\08\C0\B9\F39\7F\B9{\A9\02\03\01\00\01\A3\82\01+0\82\01'0\1F\06\03U\1D#\04\180\16\80\14\0Dk\B6\82\13\0C\A2\9D\91\01@\E8Y\D6+\EC\87\1A\F060>\06\08+\06\01\05\05\07\01\01\042000.\06\08+\06\01\05\05\070\01\86"http://ipa-ca.freeipa.home/ca/ocsp0\0E\06\03U\1D\0F\01\01\FF\04\04\03\02\04… Authority0\1D\06\03U\1D\0E\04\16\04\14\E8\11K6\86\C9|\A2\D7N\FF|\13\89+8\8D\C4\EC20\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00\03\82\01\81\00X\AF+~\FD\05\B9F\8A\C7\B9\E4\96BG-\8F\17\01\8EX0\95\9C\BE\E7-\A8"d^\FD\F5\ECF\97-\88\BC\06\B0\E7\A3w\A3\D0\B6\DA\01Os\F4=\C9GI\E2\D0\A0\E8\BD\A9b\FDl\DE\812\9A3\D5XW\D8\C9GTx\FAi I\11\C9\DCO\F4\BC7c\28j\FD\E2\F7K\0FD&\90l"\C9\B8\FF\9A6\05\A3$<XsoK\17-\E3"0\AA4N/6$\94j$\9B\BF\AC\E5#3\F6?\CF\C7\DD8\91\85c\C0aU_\DE+\E6=\13O\8Cjj\1E;\0EJ\8C\E9\C3F\EF\02\BBc\B7\09\9F\D8\5CgL\C6@\8F\1E~\C8\F0\89L\8F\F8$cB1\F9][-\CBx\C3\94_>\CA\B8{h\9Aj\09\0C"\BD\DA9\9F\B7\0FO \A9\1A\DE\D7\8A1\AF\A3\AC\14\D1\BA\90\B8"V1\B1Rxso6\05\88\0BV1\FDU\89}U\8B\01\1DX\0Cu\03\BD|{\05\C7\86\15\90\0C\F4\C6\91\D3\F6s\E9\8F\1F%\882\B2\CBS\DB\91\E4\8B\28\A1"z8\AC\F5\8B2Q\D4\9E\D6\E1\15\0D\FB\8F`\09\E5\0C\DD\D4\19\FE\F7D\CD\AC\FF\82\94\16\F5}\19W0y\96K{a\D0\B8\C3\0C\1C/\89~\01^\A0\95\9A\AA\D3\E2m\D5\FA.\E8WZ\B3E#\17@\C9\D3\92\9E\11\CC\C41\F2\E5\94\E3\8F^\D9Q\92\CDFw3\C8KP\84s)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))" Some of the hex has been decoded into readable strings, which causes the search to fail. Running the same search on FreeIPA with an identical user entry returns the entry correctly. I'm happy to provide more logs/details if needed. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10163] New: Cleanup configure/test integration
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10163 Issue ID: 10163 Summary: Cleanup configure/test integration Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The sed commandline configure uses to perform substitutions is getting unwieldy and may be exceeding platform limits on various systems. All of the BUILD_xxx substitutions for overlays are only used in tests/run.in. They could be completely removed, and instead each of the enabled overlays could be emitted into a separate file that just gets included by the test scripts. There's no need for them to be part of the sed invocation at all. There's also leftover BUILD_xxx cruft from backends that we've removed (e.g. back-shell BUILD_SHELL) that nothing else in the tree references any more. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 06 May '25

06 May '25

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 8

[Issue 10254] New: Allow upgrading password hash on bind
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10254 Issue ID: 10254 Summary: Allow upgrading password hash on bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: me(a)floriswesterman.nl Target Milestone: --- Many OpenLDAP installations are likely to contain relatively old password hashes such as SSHA and CRYPT, as modern alternatives such as Argon are only recent additions. Due to the nature of password hashes, it is of course not possible to "unhash" the old values and rehash them with a more modern algorithm. The presence of these old password hashes poses a liability in case of information leaks or hacks. Currently, the only way to upgrade a password hash is to wait for the user to change their password. This can be sped up by expiring passwords and forcing users to change them. However, this can be slow and frequent password rotation is no longer considered a best practice. It would be a very helpful addition to add support for upgrading a password hash on bind. This is implemented in the 389 directory server: https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html Essentially, when a user binds, the password is checked like normal. In case of a successful bind, the proposed feature would check the hash algorithm used for the password; and in case it is not equal to the current `olcPasswordHash` value, the user-provided password is rehashed using the new algorithm and stored. This way, the old hashes are phased out more quickly, without being a disturbance to users. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10293] New: Log operations generated by syncrepl at STATS level
by openldap-its＠openldap.org 09 Apr '25

09 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10293 Issue ID: 10293 Summary: Log operations generated by syncrepl at STATS level Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Similarly to how incoming operations are logged, operations created by syncrepl should be logged as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10322] New: Retire 2.4 admin guide
by openldap-its＠openldap.org 01 Apr '25

01 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10322 Issue ID: 10322 Summary: Retire 2.4 admin guide Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- 2.4 release stream has been dead for a while now however its Admin Guide is still in place, we should remove it and possibly have links under it 301 to admin26? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10169] New: Add support for token only authentication with otp overlay
by openldap-its＠openldap.org 27 Mar '25

27 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10169 Issue ID: 10169 Summary: Add support for token only authentication with otp overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the OTP overlay is password + token. It would be nice to be able to configure it so it can run in a token only mode, similar to the slapo-totp overlay in contrib. This would allow us to have a project supported solution and retire that contrib module. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 26 Mar '25

26 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=7901 requate(a)univention.de <requate(a)univention.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1059|0 |1 is obsolete| | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10313] New: 3-way multimaster oathHOTPCounter attribute update code missing
by openldap-its＠openldap.org 26 Mar '25

26 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10313 Issue ID: 10313 Summary: 3-way multimaster oathHOTPCounter attribute update code missing Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: agrru01(a)gmail.com Target Milestone: --- I posted on openldap technical mail list and got a response saying I should file a feature request. I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My problem is that when authenticating with a user using HOTP, the attribute oathHOTPCounter only updates the value on the target ldap instance. This means the other two ldap instances do not get the updated HOTP-counter value and therefore will allow authentication using the same HOTP code. Interestingly enough, if I manually edit the oathHOTPCounter value it synchronizes with the other masters. Please see the technical mail list discussion: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10258] New: test050 failure: connection_close race?
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

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 5

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) 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: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=7901 --- Comment #3 from requate(a)univention.de <requate(a)univention.de> --- Created attachment 1060 --> https://bugs.openldap.org/attachment.cgi?id=1060&action=edit slapschema-continuemode-and-preserve-rc.patch This extended version of the patch additionally preserves a non-zero return code even in combination with the option "-c". -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=7901 --- Comment #2 from requate(a)univention.de <requate(a)univention.de> --- Created attachment 1059 --> https://bugs.openldap.org/attachment.cgi?id=1059&action=edit slapschema-continuemode.patch If the last object checked by entry_schema_check() has a problem, then slapschema returns the error code of that problem. But if there is a good object check after that, then it returns 0. That is not ideal. The tool offers the option "-c" to activate a "continuemode". The man page states "Enable continue (ignore errors) mode" and it is a bit surprising that the default behavior is different for the the return code of the main check. Also, while the message `# (65) Object class violation: unrecognized objectClass 'foo'` is output to stdout, the messages `67e293be UNKNOWN attributeDescription "BAR" inserted.` are actually output to stderr. They seem related, maybe it would be more consistent to output them to the same channel. The attached patch just proposes to exit the check loop in case entry_schema_check() fails and the option "-c" was not given. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10316] New: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling()
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10316 Issue ID: 10316 Summary: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: stefan(a)konink.de Target Milestone: --- I am developing ETL software in Python and I am using lmdb as backend. For this I am using https://github.com/jnwatson/py-lmdb In this big process I am resizing the map_size dynamically. I would say it is certainly possible that I am reading at the same time. I end up in the following error: build/lib/mdb.c:5882: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() I ran my application again with a predetermined map size, and it did not assert. Since it is a single shot, I don't know if I can be certain that it therefore does not happen. When searching for it I found the following issue from 2017, suggesting it can be reproduced when running the performance test. https://github.com/bnclabs/dbperf/issues/1 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- No OpenLDAP issue seen. Use proper file limit settings. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10315] Re-Usage of Message IDs of async search blocks all available connections
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10315 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10318] New: Potential null-pointer-dereference in servers/slapd/connection.c
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10318 Issue ID: 10318 Summary: Potential null-pointer-dereference in servers/slapd/connection.c Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 1367173408(a)qq.com Target Milestone: --- Created attachment 1056 --> https://bugs.openldap.org/attachment.cgi?id=1056&action=edit execution trace Hi, I have found a potential null pointer dereference bug in the project and would like to report it to the maintainers. At line 267 and line 284 in file `servers/slapd/connection.c`, the function `connection_get` may return NULL. Then, at line 1239 in the same file, the pointer `c` receives the return value, which may be NULL. But `c` is dereferenced at following lines without checking, which may lead to a null-pointer-dereference bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10317] New: Potential null-pointer-dereference
by openldap-its＠openldap.org 11 Mar '25

11 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10317 Issue ID: 10317 Summary: Potential null-pointer-dereference Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 1367173408(a)qq.com Target Milestone: --- Created attachment 1055 --> https://bugs.openldap.org/attachment.cgi?id=1055&action=edit execution trace Hi, I have found a potential null pointer dereference bug in the project and would like to report it to the maintainers. At line 836 in file `servers/slapd/backglue.c`, the function `glue_tool_inst` may return NULL. Then, at line 765 in the same file, the pointer `on` receives the return value, which may be NULL. But `on` is dereferenced at line 766 without checking, which may lead to a null-pointer-dereference bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10266] New: Adopt broader RFC4511 NoD interpretation on lloadd's client side
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10266 Issue ID: 10266 Summary: Adopt broader RFC4511 NoD interpretation on lloadd's client side 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: --- Server side, lloadd has long implemented a broad interpretation of NoD unsolicited response handling: when the message is issued, no new requests are accepted on the session however the client and server are both free to keep the session open if there are any operations that have not resolved yet. The server is still expected to close the connection as soon as no operations are still pending. This seems to interoperate with known clients. Those that want to will close the session immediately, unaware of this possibility, those that also want to interpret RFC 4511 this way can choose to wait for existing operations to resolve. This ticket is to track the lloadd's implementation of the client side of this - when receiving a NoD message, we don't close the connection immediately+unconditionally either but are willing to wait. Related functionality: - if connection was a bind connection processing a multi-stage SASL bind, the bind should fail if/when the client attempts to progress it - clients assigned to this connection through coherence at least 'connection' are also marked closing -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10310] New: Update pbkdf2 overlay so iterations can be configurable
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10310 Issue ID: 10310 Summary: Update pbkdf2 overlay so iterations can be configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The pbkdf2 password hashing contrib overlay has the number of iterations hard coded at 10,000. It would be helpful to update the module to allow this to be configurable instead, as is done with other password hashing modules. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10314] New: Only install the slapi-plugin.h header if building slapi library
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10314 Issue ID: 10314 Summary: Only install the slapi-plugin.h header if building slapi library Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mattias.ellert(a)physics.uu.se Target Milestone: --- Created attachment 1054 --> https://bugs.openldap.org/attachment.cgi?id=1054&action=edit Proposed patch The slapi-plugin.h header does not make sense without the slapi library. The attached patch makes the installation of the header conditional. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2025