- openldap-bugs - openldap.org

[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

[Issue 10355] New: mplay doesn't compile on musl
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10355 Issue ID: 10355 Summary: mplay doesn't compile on musl Product: LMDB Version: 0.9.33 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: bgilbert(a)backtick.net Target Milestone: --- With the musl C library (e.g. Alpine Linux) mplay doesn't compile: gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mplay.c mplay.c: In function 'addpid': mplay.c:490:23: error: assignment of read-only variable 'stdin' 490 | stdin = fdopen(0, "r"); | ^ mplay.c:491:24: error: assignment of read-only variable 'stdout' 491 | stdout = fdopen(1, "w"); | ^ make: *** [Makefile:99: mplay.o] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10341] New: Two potential buffer overruns in function mdb_cmp_cint.
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10341 Issue ID: 10341 Summary: Two potential buffer overruns in function mdb_cmp_cint. 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 1068 --> https://bugs.openldap.org/attachment.cgi?id=1068&action=edit Patch: Fix buffer overrun in function mdb_cmp_cint We found two potential bugs in `mdb_cmp_cint`’s backward‐scan loop: ```c u = (unsigned short *)((char *)a->mv_data + a->mv_size); c = (unsigned short *)((char *)b->mv_data + a->mv_size); do { x = *--u - *--c; } while (!x && u > (unsigned short *)a->mv_data); ``` 1. **Underflow when `a->mv_size == 0`** If `a->mv_size` is zero, `u` is initialized to point one past the end of the zero‐length buffer. The first `--u` then moves it before `a->mv_data`, and the subsequent dereference is undefined. The original API allows lengths from 0 to `0xFFFFFFFF`, so a zero length is possible can could lead to pointer underflow here. 2. **Overflow of `b->mv_data` when `b->mv_size < a->mv_size`** The code uses `a->mv_size` to advance both `u` and `c`, and only bounds‐checks `u`. If `b->mv_size` is smaller than `a->mv_size`, `c` may run past the end of its buffer before the loop terminates, causing a buffer overrun. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10340] New: Potential Buffer Overflow in mdb_rebalance
by openldap-its＠openldap.org 29 Jan '26

29 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10340 Issue ID: 10340 Summary: Potential Buffer Overflow in mdb_rebalance 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 1067 --> https://bugs.openldap.org/attachment.cgi?id=1067&action=edit Add an early return when `mc->mc_top == 0` In `mdb_rebalance`, we do: ```c int ptop = mc->mc_top - 1; node = mc->mc_pg[ptop]; ``` However, `mc->mc_top` defaults to 0 in many contexts, so `ptop` can become `-1`. Indexing `mc->mc_pg[-1]` causes invalid memory access. Elsewhere this is handled by checking `mc->mc_top > 0` before decrementing. To fix this, we add an early return when `mc->mc_top == 0`. A root page (or one without a parent) doesn’t need rebalancing, so this guard prevents `ptop` from ever being negative and eliminates the out-of-bounds access. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10132] New: manage syncrepl as a cn=config entry
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry 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: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 7392] ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by openldap-its＠openldap.org 27 Jan '26

27 Jan '26

1 0

[Issue 10426] New: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds)
by openldap-its＠openldap.org 20 Jan '26

20 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10426 Issue ID: 10426 Summary: liblber: ber_get_stringbvl integer overflow enables heap buffer overflow via {M} parsing (32-bit builds) Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: lukas(a)artiphishell.com Target Milestone: --- Created attachment 1105 --> https://bugs.openldap.org/attachment.cgi?id=1105&action=edit build.sh ## Issue description Vulnerable location: `libraries/liblber/decode.c` in `ber_get_stringbvl()` Root cause: in the first pass that counts elements, `tot_size += siz` is performed with `ber_len_t` and no overflow check. On 32-bit builds, a large BER sequence (e.g., SearchRequest attributes parsed via `{M}`) wraps `tot_size`. The allocation uses the wrapped value (`ber_memalloc_x(tot_size + siz, ...)`), producing an undersized buffer. The second pass then writes `i` elements into the vector (BvOff mode for `{M}`), advancing `tot_size` by `siz` and storing `struct berval` at `res.bo + tot_size`, which overruns the allocation. Call path observed in the ASAN trace: `slapd` -> `do_search` (`servers/slapd/search.c:145`, `ber_scanf("{M}}")`) -> `ber_scanf` (`libraries/liblber/decode.c:815`) -> `ber_get_stringbvl` (`libraries/liblber/decode.c:471`) -> heap buffer overflow. ## Reproduction Steps Build instructions: ```bash mkdir /tmp/openldap-ber-get-stringbvl-overflow cd /tmp/openldap-ber-get-stringbvl-overflow # create the following files in this directory chmod +x build.sh poc.sh git clone https://github.com/openldap/openldap ./build.sh ./openldap # Run the PoC ./poc.sh ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 12 Jan '26

12 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #29 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 8ba07ad7 by Howard Chu at 2025-12-16T17:33:38+00:00 ITS#8988 lmdb: make all keys and data 2-byte aligned -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8178] back-sock: Timeout to avoid locking
by openldap-its＠openldap.org 07 Jan '26

07 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=8178 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- back-sock currently uses stdio (fgets()) to read from the socket, the thing would need to be reworked to move away from STDIO towards non-blocking read() and select(). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=9884 Issue ID: 9884 Summary: Document "set" patterns in ACLs Product: OpenLDAP Version: unspecified 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: --- The slapd.access(5) man page has this exceptionally unhelpful line where sets are concerned: "The statement set=<pattern> is undocumented yet." Even if it is an experimental feature, it should still be documented on how it is meant to operate. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8070] test023 failures
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=8070 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- depends on migration to python test suite -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7347] Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=7347 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- commit 93d7b9ef7af5747859b82f4326661728106b0149 Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Wed Dec 10 12:07:18 2025 +0000 ITS#7347 Allow subtractive -a/z/i to work as expected -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7347] Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=7347 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #10 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/814 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10417] New: Objects not receivable anymore after schema attribute name /alias change
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10417 Issue ID: 10417 Summary: Objects not receivable anymore after schema attribute name /alias change Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: best(a)univention.de Target Milestone: --- Created attachment 1100 --> https://bugs.openldap.org/attachment.cgi?id=1100&action=edit ITS10417.txt We have objects in the directory which cannot be received anymore after we change the schema. The objects are returned in a search but using the DN as search base yields NO SUCH OBJECT error code. The schema change: Add another NAME for the existing attribute and put it into the first (canonical) position. The attribute is used as RDN component for objects. Schema change as (unified) diff: ```diff -attributetype ( 1.3.6.1.4.1.10176.4221.1.10 NAME 'univentionRecycleBinOriginalUniventionObjectIdentifier' +attributetype ( 1.3.6.1.4.1.10176.4221.1.10 + NAME ('univentionRecycleBinID' 'univentionRecycleBinOriginalUniventionObjectIdentifier') DESC 'Original univentionObjectIdentifier of the deleted object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) objectclass ( 1.3.6.1.4.1.10176.4221.2.2 NAME 'univentionRecycleBinObject' DESC 'Object stored in the Recycle Bin' SUP top STRUCTURAL MUST ( univentionRecycleBinOriginalDN $ univentionRecycleBinDeleteAt $ - univentionRecycleBinOriginalUniventionObjectIdentifier $ + univentionRecycleBinID $ univentionRecycleBinOriginalObjectClass $ univentionRecycleBinDeletionDate $ univentionRecycleBinOriginalEntryUUID $ univentionRecycleBinOriginalType ) MAY ( univentionObjectIdentifier $ univentionObjectType $ univentionRecycleBinReference ) ) ``` Now the proof script: It searches for a certain example object. And get its DN. (stored in a variable with correct LDAP DN escape sequences). Then it searches for that object. → no result Then it searches for a modified DN so that its RDN uses a new name → no result Then it searches for a modified DN so that its RDN uses the OID → no result ```bash start="$(date '+%Y-%m-%d %H:%M:%S')" sleep 1 ldaps () { ldapsearch -o ldif-wrap=no -ZZ -D cn=master,cn=dc,cn=computers,dc=ucs,dc=test -y /etc/machine.secret -LLL "$@" } DN=$(ldaps -LLLb 'cn=recyclebin,cn=internal' univentionRecycleBinID=785c156b-bc84-4cb2-b34d-e10d78065a57 1.1 | sed -ne 's/^dn: //p') echo "$DN" ldaps -b "$DN" 1.1 ldaps -b "$(echo "$DN" | sed 's/univentionRecycleBinOriginalUniventionObjectIdentifier/univentionRecycleBinID/g')" 1.1 ldaps -b "$(echo "$DN" | sed 's/univentionRecycleBinOriginalUniventionObjectIdentifier/1.3.6.1.4.1.10176.4221.1.10/g; s/univentionRecycleBinOriginalDN/1.3.6.1.4.1.10176.4221.1.5/')" 1.1 sleep 1 end="$(date '+%Y-%m-%d %H:%M:%S')" journalctl --since="$start" --until="$end" ``` The command output and logs are attached, with stripped date prefix. The logs show, that OL normalizes the DN internally. So the search by OID, or alias is not a problem. I don't know yet, (but i would suspect it), if OL backends store object DNs internally by storing AVA-lists with OIDs: [[(OID, value, AVA_TYPE), …], …] --- Background of our schema change reasoning: We have very long RDN components now and reach some MDB limits. I don't know if the limit only affect RDN values or as well the RDN attribute-names. But also for user-friendly-ness we want to shorten the DN name. ldap.OTHER: {'msgtype': 105, 'msgid': 3, 'result': 80, 'desc': 'Other (e.g., implementation specific) error', 'ctrls': []} slapd[28205]: => mdb_dn2id_add 0x3fb: "univentionRecycleBinOriginalDN=uid\3Dumc_test_user_xvju2bhb6t\2Ccn\3Dintermediate_test_container\2Ccn\3Dbase_test_container\2Cdc\3Dautotest092\2Cdc\3Daaaa+univentionRecycleBinOriginalUniventionObjectIdentifier=675f8041-87d9-4483-9c46-e558f9f58c7f,cn=recyclebin,cn=internal" slapd[28205]: <= mdb_dn2id_add 0x3fb: -30781 slapd[28205]: mdb_add: dn2id_add failed: MDB_BAD_VALSIZE: Unsupported size of key/DB name/data, or wrong DUPFIXED size (-30781) So we want to change: univentionRecycleBinOriginalDN = {DN} + univentionRecycleBinOriginalUniventionObjectIdentifier = {UUID} , cn = recyclebin , cn = internal to: univentionRecycleBinID = {UUID} , parent(DN) , cn = recyclebin , cn = internal But we must be backward compatible to a certain degree for old productive systems. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10418] New: Typo in man page for slapcat
by openldap-its＠openldap.org 06 Jan '26

06 Jan '26

https://bugs.openldap.org/show_bug.cgi?id=10418 Issue ID: 10418 Summary: Typo in man page for slapcat Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: hanspeter.dekoning(a)dekonsult.com Target Milestone: --- In the slapcat man page, in the description of option -o under "Possible generic options/values are:" the following option is misspelled: ldif_wrap={no|<n>} the underscore should be a hyphen, like so: ldif\-wrap={no|<n>} Location is line 152 in: https://git.openldap.org/openldap/openldap/-/blob/master/doc/man/man8/slapc… Correction tested and confirmed with slapcat in v2.6.10 on Linux / Ubuntu v24.04. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 5808] jldap library connect timeout doesn't work
by openldap-its＠openldap.org 18 Dec '25

18 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=5808 --- Comment #5 from Norbert Klasen <klasen(a)gmx.net> --- The link for "SocketFactory does not support a connect timeout" should have been https://bugs.openjdk.org/browse/JDK-4414843 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 16 Dec '25

16 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=8988 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Target Milestone|0.9.34 |1.0.0 Status|CONFIRMED |RESOLVED --- Comment #28 from Howard Chu <hyc(a)openldap.org> --- Fixed in 8ba07ad71138d7735df9225638f436dc060266b0 in mdb.master3 Note that this is an incompatible DB format change, DBs must be dumped and reloaded. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs