openldap-bugs June 2026

openldap-bugs@openldap.org

1 participants
67 discussions

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

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

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=6198 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • e922f9f1 by Ondřej Kuzník at 2026-06-08T01:31:08+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options RE27: • 0e10c595 by Ondřej Kuzník at 2026-06-08T18:07:59+00:00 ITS#6198 doc: Extend admin guide ACL section to cover new options -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10517] New: mbedTLS doesn't verify certificate in reqcert try mode
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10517 Issue ID: 10517 Summary: mbedTLS doesn't verify certificate in reqcert try mode Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When setting the authmode to OPTIONAL, mbedTLS documentation[0] says that it's the user's responsibility to check the verification result if they care. `reqcert try` does care, but mbedtls_ssl_get_verify_result is never called in that case and so an invalid cert is not detected (easy to test by changing line 204 in test067). [0]. https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#a569528… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10515] New: Miscellaneous Windows issues
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10515 Issue ID: 10515 Summary: Miscellaneous Windows issues Product: OpenLDAP Version: unspecified 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: --- Just opened this ticket to have some place to assign further fixes for issues on Windows. Both related to compilation and to running the test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10516] New: dynamic backends don't get rebuilt
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10516 Issue ID: 10516 Summary: dynamic backends don't get rebuilt Product: OpenLDAP Version: unspecified 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 makefile rules need a small fix. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9009 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- mdb.RE/1.0: • ce139ac9 by Howard Chu at 2026-06-04T21:42:15+01:00 ITS#9009 LMDB add release notes/upgrading info mdb.master3: • b7c68db2 by Howard Chu at 2026-06-04T21:41:32+01:00 ITS#9009 LMDB add release notes/upgrading info -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8901] slapd segfaults in mdb_env_reader_dest
by openldap-its＠openldap.org 08 Jun '26

08 Jun '26

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

1 0

[Issue 10508] New: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn
by openldap-its＠openldap.org 03 Jun '26

03 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=10508 Issue ID: 10508 Summary: syncrepl: be_modrdn / message_to_op called without orm_no_opattrs=1, modifiersName clobbered by consumer rootdn Product: OpenLDAP Version: 2.6.13 Hardware: i386 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: apostnikov(a)gmail.com Target Milestone: --- Created attachment 1150 --> https://bugs.openldap.org/attachment.cgi?id=1150&action=edit 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch When syncrepl applies provider changes locally it invokes the backend through be_add / be_modify / be_modrdn / be_delete, carrying the provider's operational attributes in the modlist. Without `op->orm_no_opattrs = 1` the backend (verified on back-mdb; servers/slapd/back-mdb/modrdn.c:76 and modify.c:619) calls slap_mods_opattrs(), which auto-injects a `replace modifiersName=<op->o_dn>` mod whenever modifiersName is not already present in the modlist. For syncrepl, `op->o_dn` is the consumer's local rootdn (set at syncrepl.c:2165 — `op->o_dn = op->o_bd->be_rootdn`), so the consumer ends up with `modifiersName=cn=<consumer-rootdn>` instead of the provider's value. ITS#4820 originally papered over this in syncrepl_diff_entry() with a kludge that always forced modifiersName/modifyTimestamp into the diff (`if (*mods && (modifiersName||modifyTimestamp)) attr_cmp(NULL,new)`). ITS#10250 commit 87933f3e removed that kludge with the rationale "the mod is being passed to the backend with orm_no_opattrs these days". But two code paths in syncrepl.c never actually set orm_no_opattrs: 1. syncrepl_entry() refresh-mode rename-with-content path (around line 4788 on master): the parallel be_modify branch sets `orm_no_opattrs = 1/0` around its call; the be_modrdn branch does not. 2. syncrepl_message_to_op() (delta-sync log replay; whole function from line 3180 on master): none of the four backend dispatches (be_add, be_modify, be_modrdn, be_delete) set the flag. Once 87933f3e removed the kludge, the auto-inject surfaced whenever provider and consumer happened to already agree on modifiersName so syncrepl_diff_entry produced no mod for it. Whether that happens for a given entry depends on attribute iteration order in the diff (attribute hash bucket order), which is why x86_64/aarch64 mostly mask the bug while x86/armv7/armhf/s390x (QEMU builders) trigger it deterministically and ppc64le sees it as flake in test063. Worst case the consumer ends up with the provider's entryCSN (the modrdn bumped it) but the wrong modifiersName, and ITS#10358's assert-retry then sees identical entryCSN, takes no further action, and the corruption is permanent until something else updates the entry. Reproducer ---------------------------------------------------------------- Native: 32-bit or big-endian build of HEAD; run cd tests make BACKEND=mdb mdb-mod TESTS=test017-syncreplication-refresh Cross-arch via Alpine's CI image (any host): docker run --rm --platform linux/386 -v $PWD:/mnt \ registry.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci:latest-x86 \ sh -c 'cd /mnt && ./configure --enable-modules --enable-mdb=mod \ --enable-syncprov=mod && make && cd tests && make mdb-mod' Expected on affected builders: >>>>> Starting test017-syncreplication-refresh for mdb... ... test failed - provider and consumer databases differ >>>>> Failed test017-syncreplication-refresh for mdb Capturing the diff (modify defines.sh's CMPOUT temporarily) shows: 348c348 < description: Example, Inc. ITS test domain --- > description: Example, Inc. modify+modrdn test domain 350c350 < modifiersName: cn=Manager,dc=example,dc=com --- > modifiersName: cn=consumer,dc=example,dc=com (Both entries carry the SAME final entryCSN — that's the smoking gun: the consumer adopted the provider's CSN via the modrdn, but the follow-up modify hit `err=122 LDAP_ASSERTION_FAILED` because of the CSN bump, and ITS#10358's retry then short-circuited.) Proposed fix ---------------------------------------------------------------- Six added lines in servers/slapd/syncrepl.c — see attached patch 0001-syncrepl-set-orm_no_opattrs-for-backend-ops.patch. Tested against OPENLDAP_REL_ENG_2_6_13: full make test suite passes on x86 (linux/386 QEMU) including all six tests that ITS#10250 patched plus test043-delta-syncrepl and test063-delta-multiprovider. References / related ITS ---------------------------------------------------------------- ITS#4820 — the original modifiersName/modifyTimestamp kludge added in 2007 ITS#10250 — kludge removed (MR#817, commit 87933f3e), exposing this bug ITS#10358 — assert-control retry (MR#781) — masks the divergence as silent data loss ITS#8852 — sorted_attr_cmp() prerequisite for ITS#10250 (commit 8986f99d) -- You are receiving this mail because: You are on the CC list for the issue.

1 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2026