https://bugs.openldap.org/show_bug.cgi?id=10511
Issue ID: 10511
Summary: Add pagesize setting to back-mdb
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
With LMDB 1.0, the DB pagesize is now configurable. Add an option to back-mdb
to support this. Larger page sizes accommodate larger keys, which is also
helpful when using multival.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10510
Issue ID: 10510
Summary: write_coherence can assert() on unbind
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If lloadd links a client with a backend and that client issues a write and
unbind in quick succession, the self-checks in client_reset are overly strict,
triggering an assert.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10507
Issue ID: 10507
Summary: Remove back-perl from OpenLDAP 2.7
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP 2.6 deprecated back-perl, so remove it from the 2.7 release branch
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9796
Issue ID: 9796
Summary: Deprecate GnuTLS support
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due
to the license objections at the time that the Debian project had for the
OpenSSL license.
Since that time, Debian has reclassified OpenSSL as a core library and the
OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and
later under the Apache License v2.
Thus there is no longer a reason to maintain support for GnuTLS and given the
long standing concerns over the security and quality of the GnuTLS bridge in
addition to the extra cost of maintaining that code, it should be marked as
deprecated and removed in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10502
Issue ID: 10502
Summary: feature proxyauthz should become default
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Most stock lloadd deployments are against OpenLDAP, but since "feature" keyword
doesn't allow "off-switches", proxyauthz has had to have been an "off by
default" thing. This is insecure and probably a footgun for many.
We'll have to introduce a new configuration option to do this, one that allows
for gentler evolution.
This also allows us to reject a bindconf+no_proxyauthz combinations if we force
the rare admins who genuinely need it (no proxyauthz support in upstreams) to
opt in explicitly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10415
Issue ID: 10415
Summary: Allow limiting the buffers for data pending to be sent
to client
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
In many scenarios it is more useful to limit the amount of data we buffer to be
written to the client's socket even if it means that sometimes a connection
might have to be dropped abruptly to enforce this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10162
Issue ID: 10162
Summary: Fix for binary attributes data corruption in back-sql
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: dex.tracers(a)gmail.com
Target Milestone: ---
Created attachment 1006
--> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit
Fix for binary attributes corruption on backed-sql
I've configured slapd to use back-sql (mariadb through odbc) and observed
issues with the BINARY data retrievals from the database. The length of the
attributes was properly reported, but the correct data inside was always 16384
bytes and after that point - some junk (usually filled-up with AAAAAAAA and
some other attributes data from memory).
During the debugging - I've noticed that:
- The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for
BINARY columns when SQLBindCol is done inside of the
"backsql_BindRowAsStrings_x" function
- After SQLFetch is done - data in row->cols[i] is fetched up to the specified
MAX_ATTR_LEN
- After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is
represented inside of the row->value_len
I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills
it with the specified amount of data (MAX_ATTR_LEN), but when forming the
actual attribute data - uses the length from row->value_len and so everything
from 16384 bytes position till row->value_len is just a junk from the memory
(uninitialized, leftovers, data from other variables).
After an investigation, I've find-out that:
- for BINARY or variable length fields - SQLGetData should be used
- SQLGetData supports chunked mode (if length is unknown) or full-read mode if
the length is known
- it could be used in pair with SQLBindCol after SQLFetch (!)
Since we have the correct data length inside of row->value_len, I've just added
the code to the backsql_get_attr_vals() function to overwrite the corrupted
data with the correct data by issuing SQLGetData request. And it worked -
binary data was properly retrieved and reported over LDAP!
My current concerns / help needed - I'm not very familiar with the memory
allocation/deallocation mechanisms, so I'm afraid that mentioned change can
lead to memory corruption (so far not observed).
Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and
applied on the master branch for easier review/application).
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=10505
Issue ID: 10505
Summary: lloadd doesn't fully validate incoming msgids
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
This can allow rogue clients reach an assert(0) with the right timing.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10503
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|IN_PROGRESS |RESOLVED
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• 9b55792b
by Howard Chu at 2026-05-19T16:39:09+00:00
ITS#10503 authzTo: reject member attributes with non-DN syntax
RE27:
• 0c8a5875
by Howard Chu at 2026-05-19T22:36:36+00:00
ITS#10503 authzTo: reject member attributes with non-DN syntax
RE26:
• 41d7478a
by Howard Chu at 2026-05-19T23:00:51+00:00
ITS#10503 authzTo: reject member attributes with non-DN syntax
--
You are receiving this mail because:
You are on the CC list for the issue.