https://bugs.openldap.org/show_bug.cgi?id=10509
Issue ID: 10509
Summary: 2.7: Feature notes for announcement file
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: ---
Add feature notes for the 2.7 announcement file
--
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=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.
https://bugs.openldap.org/show_bug.cgi?id=10353
Issue ID: 10353
Summary: No TLS connection on Windows because of missing
ENOTCONN in socket.h
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: julien.wadel(a)belledonne-communications.com
Target Milestone: ---
On Windows, the TLS connection cannot be done and we get the connection error:
Can't contact LDAP server.
=> Connections are done with WSAGetLastError().
After getting WSAEWOULDBLOCK, the connection is not restart because of the
state WSAENOTCONN that is not known.
OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN
is 10057L.
Adding #define ENOTCONN WSAENOTCONN
like for EWOULDBLOCK resolve the issue.
Reference commit on external project:
https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10514
Issue ID: 10514
Summary: another mutex bug in back-monitor
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: ---
Same as #1710 but introduced later in 127ac65c447b8d28ba3cd75e1b8cee28006d5472
Calling mutex_destroy on a locked mutex in cache.c:314 monitor_cache_remove().
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=8901
--- Comment #10 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Marcelo.DeCastroLoebens from comment #9)
> (In reply to Howard Chu from comment #8)
> > Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/888
> > please test.
>
> Thanks for the fix and the speedy replies.
>
> I will start testing the integration of this patch with our system. Will
> need some time (can't say for sure how much) since the occurrence is low, I
> will leave a test env cycling the shutdown over a bunch of times, then
> report here the results.
For reference, the direct way to verify this fix is to check for proper
thread pool cleanup after throwing a bit of load at the server.
I did this using test008 in the test suite.
tests% ./run -k test008
The -k flag tells it not to kill slapd after the test finishes. Then
attach to the server with gdb and set a breakpoint on the last line
of the ldap_pvt_thread_pool_close() function. (tpool.c:907 with this
patch). Then send slapd a signal to tell it to shutdown. When it hits
the breakpoint, there should be no more threadpool worker threads left.
I've tested on Linux and Windows and verified proper cleanup here.
--
You are receiving this mail because:
You are on the CC list for the issue.