openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

[Issue 6083] ppolicy should also support invocation of an external password checker
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- On Wed, Jun 04, 2025 at 10:59:16AM +0000, openldap-its(a)openldap.org wrote: > PS: and I would like to check, if a password is compromised. I already have an > external checker for this. It just needs an interface to OpenLDAP. Information > about compromised passwords and it's importance can be found at > https://haveibeenpwned.com/ Hi Heiko, if that's what you need, you could write your own policy checker wrapper. If you feel you can design an interface fit for wider use, you can even submit it for inclusion and it will be considered. But remember the slapd-sock overlay exists already and should be able to intercept the password change just fine if you don't need access to the rest of the entry being changed. Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 05 Jun '25

05 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified 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: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6083] ppolicy should also support invocation of an external password checker
by openldap-its＠openldap.org 04 Jun '25

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #4 from Heiko Zelt <hz(a)heikozelt.de> --- PS: and I would like to check, if a password is compromised. I already have an external checker for this. It just needs an interface to OpenLDAP. Information about compromised passwords and it's importance can be found at https://haveibeenpwned.com/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6083] ppolicy should also support invocation of an external password checker
by openldap-its＠openldap.org 04 Jun '25

04 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=6083 --- Comment #3 from Heiko Zelt <hz(a)heikozelt.de> --- I need this feature too. I would like to check if passwords contain only ASCII characters, and a minimum of one uppercase, lowercase, digit and special character. An external password syntax checker would be the most flexible solution. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 10336] New: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10336 Issue ID: 10336 Summary: slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion 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: A.Asemov(a)edpnet.com Target Milestone: --- slapd crashes with segfault in mdb_delete.c on non-existent tree part deletion. Applies to 2.6.7, 2.6.8, 2.6.9 ---------- Prerequisites: ---------- - mdb backend - empty mdb database ---------- Sample reproducer: ---------- ldapdelete -x -H ldap://127.0.0.1 -w "password" -D "cn=MyApplication,dc=Contacts,dc=MyTree" "dc=Contacts,dc=MyTree" ---------- Expected behavior: ---------- ldap_delete: No such object (32) ---------- Actual behavior: ---------- Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005566507b96e0 in mdb_delete (op=0x7f3f0c002910, rs=0x7f3f19bfd8a0) at ../../../../openldap-epel-2.6.8/openldap-2.6.8/servers/slapd/back-mdb/delete.c:151 ---------- Sample slapd.conf: ---------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap #moduleload back_shell.la moduleload sssvlv.la moduleload valsort.la TLSCACertificatePath /etc/openldap/certs TLSCertificateFile /etc/<path removed>.crt TLSCertificateKeyFile /etc/<path removed>.key database mdb suffix "dc=Contacts,dc=MyTree" directory "/var/lib/ldap" checkpoint 1024 1 dbnosync maxsize 1048576000 index objectClass eq,pres index ou,cn eq,pres,sub index uidNumber,gidNumber eq,pres index uid eq,pres,sub rootdn "cn=MyApplication,dc=Contacts,dc=MyTree" rootpw "{SSHA}<removed>" access to * by dn="cn=Phone,dc=Contacts,dc=MyTree" read by peername.ip=127.0.0.1 write by anonymous auth by * none overlay sssvlv sssvlv-max 1000 sssvlv-maxperconn 1000 ---------- Sample fix: I am not versed in OpenLDAP code so I can't tell if it's semantically correct. Seems like "e" gets NULL in this piece of code and the piece of code does not verify if "e" is NULL. Adding check for ( e ) makes slapd correctly return ldap_delete: No such object (32) instead of segfaulting. ---------- --- a/servers/slapd/back-mdb/delete.c 2024-05-21 19:19:11.000000000 +0200 +++ b/servers/slapd/back-mdb/delete.c 2025-05-12 14:43:04.652396852 +0200 @@ -148,17 +148,19 @@ "<=- " LDAP_XSTRING(mdb_delete) ": no such object %s\n", op->o_req_dn.bv_val ); - rs->sr_matched = ch_strdup( e->e_dn ); - if ( is_entry_referral( e )) { - BerVarray ref = get_entry_referrals( op, e ); - rs->sr_ref = referral_rewrite( ref, &e->e_name, - &op->o_req_dn, LDAP_SCOPE_DEFAULT ); - ber_bvarray_free( ref ); - } else { - rs->sr_ref = NULL; + if ( e ) { + rs->sr_matched = ch_strdup( e->e_dn ); + if ( is_entry_referral( e )) { + BerVarray ref = get_entry_referrals( op, e ); + rs->sr_ref = referral_rewrite( ref, &e->e_name, + &op->o_req_dn, LDAP_SCOPE_DEFAULT ); + ber_bvarray_free( ref ); + } else { + rs->sr_ref = NULL; + } + mdb_entry_return( op, e ); + e = NULL; } - mdb_entry_return( op, e ); - e = NULL; rs->sr_err = LDAP_REFERRAL; rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED; -- 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 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 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=7249 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 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

← Newer
1
2
3
4
5
6
7
...
2100
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs