openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[Issue 10376] New: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10376 Issue ID: 10376 Summary: 'this' seems to be duplicated in '8.4.5. Managing access with Groups' section Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: truth_jp_4133(a)yahoo.co.jp Target Milestone: --- At the sentense 'One can then grant access to the members of this this group by adding appropriate by group clause to an access directive in slapd.conf(5).' in '8.4.5. Managing access with Groups' section, 'this' seems to be duplicated. https://www.openldap.org/doc/admin26/access-control.html -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10408] New: syncprov_op_search bailout: branch doesn't expect sop removal happened already
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10408 Issue ID: 10408 Summary: syncprov_op_search bailout: branch doesn't expect sop removal happened already 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: --- There are codepaths in syncprov_op_search that reach 'bailout:' when it's possible for syncprov_op_abandon to have snuck in and remove the 'syncops *' from the list in the meantime. However this branch always expects to find it there. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10398] New: memberof and refint clash on subtree renames
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10398 Issue ID: 10398 Summary: memberof and refint clash on subtree renames Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If a group and its members are under a subtree that got renamed, refint will trigger, and try to update all the relevant DNs. When it processes the group entry, it will issue Modifies to update the DNs of the group's members. The memberof overlay will see these modifies and start trying to update the corresponding memberof values but will only succeed halfway. It will try to delete the old memberof value from the old member DN's entry, which fails because the subtree has renamed all the entries. Then it will try to add the new memberof value to the new member DN's entry, which succeeds. Then eventually refint will try to process the member's. It will try to delete the old memberof value from the new entry, and add the new memberof value to the entry. This modify request fails because the new value is already present. The entry is left with a memberof value that points to the obsolete group DN. The solution is for refint to set the manageDsaIt control on its repair ops, and for memberof to ignore Modify requests with this control set. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10369] New: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10369 Issue ID: 10369 Summary: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- When trying to modify the olcDbCheckpoint, I get an error on the olcMultiProvider attribute Here are the logs I get: juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD dn="olcDatabase={3}mdb,cn=config" juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD attr=olcDbCheckpoint juil. 17 13:03:32 openldap1 slapd[17224]: slap_get_csn: conn=1012 op=3 generated new csn=20250717130332.671384Z#000000#00b#000000 manage=1 juil. 17 13:03:32 openldap1 slapd[17224]: slap_queue_csn: queueing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: Entry (olcDatabase={3}mdb,cn=config), attribute 'olcMultiProvider' cannot have multiple values juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 RESULT tag=103 err=19 qtime=0.000008 etime=0.000185 text=attribute 'olcMultiProvider' cannot > juil. 17 13:03:32 openldap1 slapd[17224]: slap_graduate_commit_csn: removing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=4 UNBIND Here is the content of the olcDatabase={3}mdb,cn=config entry: "olcDatabase={3}mdb,cn=config", { "objectClass":[ "olcDatabaseConfig", "olcMdbConfig" ], "olcDatabase":"{3}mdb", "olcDbDirectory":"/usr/local/openldap/data/worteks/", "olcSuffix":[ "o=service,o=worteks" ], "olcAccess":[ "{0}to * by dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" read by dn=\"uid=repl,ou=security,o=service,o=worteks\" read by anonymous auth by * none break", "{1}to attrs=userPassword by * none", "{2}to dn.subtree=\"ou=security,o=service,o=worteks\" by * none", "{3}to * by * none" ], "olcAddContentAcl":true, "olcLimits":[ "{0}dn=\"uid=repl,ou=security,o=service,o=worteks\" size=unlimited time=unlimited", "{1}dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" size=unlimited time=unlimited" ], "olcRootDN":"cn=admin,o=service,o=worteks", "olcRootPW":"secret", "olcSyncrepl":[ "{0}rid=012 provider=ldap://openldap1:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog", "{1}rid=011 provider=ldap://openldap2:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog" ], "olcMultiProvider":true, "olcDbCheckpoint":"1024 1", "olcDbNoSync":true, "olcDbIndex":[ "entryUUID eq", "objectClass eq", "entryCSN eq", "uid eq", "mailboxServiceIMAP eq", "mailboxServicePOP eq", "mailPrimaryAddress eq", "mailAlternativeAddress eq", "mailboxHiddenAlias eq" ], "olcDbMaxSize":137438953472 } In this context, I'm trying to modify the incorrect olcDbCheckpoint value from '1024 1' to '0 1', and the olcMultiProvider has only one value. -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 10410] Buffer overflow in logging.c slapd module
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

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

1 0

[Issue 10420] New: Add support for building on Haiku
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10420 Issue ID: 10420 Summary: Add support for building on Haiku Product: LMDB Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: alizter(a)gmail.com Target Milestone: --- The following patch allows for lmdb to be built on Haiku: ``` diff --git a/vendor/ocaml-lmdb/mdb.c b/vendor/ocaml-lmdb/mdb.c index 64e5ffd254..ffd8618ffa 100644 --- a/vendor/ocaml-lmdb/mdb.c +++ b/vendor/ocaml-lmdb/mdb.c @@ -174,6 +174,9 @@ # endif #elif defined(__ANDROID__) # define MDB_FDATASYNC fsync +#elif defined(__HAIKU__) +# define MDB_USE_POSIX_SEM 1 +# define MDB_FDATASYNC fsync #endif ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10419] New: NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10419 Issue ID: 10419 Summary: NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED Product: LMDB Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: alizter(a)gmail.com Target Milestone: --- NetBSD does not define union semun nor set _SEM_SEMUN_UNDEFINED. This means that the union defined when _SEM_SEMUN_UNDEFINED is set is skipped leading to a compilation error. Adding this to `mdb.c` will fix this issue by setting this variable in NetBSD when it is undefined (and it usually is, I can't speak for the future). ``` diff --git a/mdb.c b/mdb.c index 3e3f529b98..64e5ffd254 100644 --- a/vendor/ocaml-lmdb/mdb.c +++ b/vendor/ocaml-lmdb/mdb.c @@ -176,6 +176,11 @@ # define MDB_FDATASYNC fsync #endif +/* NetBSD does not define union semun in sys/sem.h */ +#if defined(__NetBSD__) && !defined(_SEM_SEMUN_UNDEFINED) +# define _SEM_SEMUN_UNDEFINED 1 +#endif + #ifndef _WIN32 #include <pthread.h> #include <signal.h> ``` FreeBSD and OpenBSD don't suffer from this issue as they both correctly set that variable. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10432] New: filter with typo'ed attribute name causes 0 results
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10432 Issue ID: 10432 Summary: filter with typo'ed attribute name causes 0 results Product: OpenLDAP Version: 2.6.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: simon.leary42(a)proton.me Target Milestone: --- Here is a filter for posixAccount entries missing the sshPublicKey attribute: ``` (&(objectClass=posixAccount)(!(sshPublicKey=*))) ``` It works normally. If I made a typo and instead searched for entries missing some other bogus attribute name: ``` (&(objectClass=posixAccount)(!(ssshPublicKey=*))) ``` I get 0 results. None of my posixAccounts have an `ssshPublicKey` attribute, so I would think that the right half of my filter should be always true. So every posixAccount should be returned. Am I wrong to think that? Note: the `!(foo=*)` syntax comes from [stackoverflow](https://stackoverflow.com/questions/14441529/ldap-filter-for… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10342] New: Potential Memory Leak in function mdb_txn_begin
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10342 Issue ID: 10342 Summary: Potential Memory Leak in function mdb_txn_begin Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: alexguo1023(a)gmail.com Target Milestone: --- Created attachment 1069 --> https://bugs.openldap.org/attachment.cgi?id=1069&action=edit Free txn->mt_u.dirty_list before freeing txn The function `mdb_txn_begin` allocates the dirty list via ```c txn->mt_u.dirty_list = malloc(sizeof(MDB_ID2) * MDB_IDL_UM_SIZE); ``` Later, when `txn != env->me_txn0`, it calls ```c free(txn); ``` without first freeing `txn->mt_u.dirty_list`. This orphaned allocation leads to a memory leak. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10421] New: mdb_load can crash on malicious input
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10421 Issue ID: 10421 Summary: mdb_load can crash on malicious input Product: LMDB Version: 0.9.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: minor Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This is being reported as a DOS vulnerability, which is incorrect. https://www.socdefenders.ai/item/01d72f7a-9622-4384-a936-d99925a19a8f mdb_load is a command-line tool, not a server nor a library function that could be run in a server. There is no service to deny. Reading a line containing an embedded NUL byte may cause mdb_load to crash, but as it's a one-shot commandline tool such crashes have no consequences. The report claims "heap metadata leak" which is also irrelevant since this is a one-shot tool and the only potential metadata is that which was contained in the input file, whose contents are already known to the attacker. The report is supposedly released under "responsible disclosure" and yet it was never reported directly to the OpenLDAP Project (not in this bug tracker nor anywhere else). This despite the fact that the reporter clearly knows that mdb_load is a piece of OpenLDAP software. https://seclists.org/fulldisclosure/2026/Jan/5 The malicious input file must be constructed with a valid header and a line containing a single space followed by a single NUL byte. The dump/load file format only uses printable characters, so an embedded NUL byte never occurs in valid files. It is unclear why any DB admin would ever fall victim to such a malicious input. The mdb_load utility is only used to load files generated by mdb_dump, and mdb_dump will never produce such an invalid file. If an attacker went to the trouble to binary patch a dump file to create this crashing character sequence, they clearly have enough privileges to read and alter any other relevant files, so this crash doesn't give them any particular advantage. Nor does the crash reveal any memory content that they don't already know. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs