openldap-bugs

openldap-bugs@openldap.org

1 participants
21026 discussions

[Issue 10350] New: Free ch_calloc-allocated memory in error paths
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10350 Issue ID: 10350 Summary: Free ch_calloc-allocated memory in error paths Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1079 --> https://bugs.openldap.org/attachment.cgi?id=1079&action=edit Free ch_calloc-allocated memory in error paths 1. In aa_operational, bv_allowed and bv_effective are allocated via ch_calloc. If ja == 0 or je == 0, these memory objects are never freed and do not escape the function, causing potential memory leak. 2. In memberof_db_init, the memory allocated by ch_calloc isn’t released on error paths, leading to another potential leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10351] New: olcSaslHost lacks default value
by openldap-its＠openldap.org 10 Jun '25

10 Jun '25

https://bugs.openldap.org/show_bug.cgi?id=10351 Issue ID: 10351 Summary: olcSaslHost lacks default value Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: fredrik(a)falk-net.se Target Milestone: --- I'm trying to configure multi-master replication with SASL for cn=config and some other databases. However, I'm running into an issue with GSSAPI/SASL as it also syncs olcSaslHost, which has to be unique to each host in order to work. I'd like if olcSaslHost was left empty then it'd default to the hostname/FQDN of the host running slapd, which would resolve the issue. This issue has been encountered before: https://www.openldap.org/lists/openldap-technical/201508/msg00124.html https://www.openldap.org/lists/openldap-technical/201001/msg00048.html -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

22 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 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 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 22 May '25

22 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

← Newer
1
...
5
6
7
8
9
10
11
...
2103
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