https://bugs.openldap.org/show_bug.cgi?id=10299
Issue ID: 10299
Summary: slapacl -u segfaults on nonexistent user
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: ratness(a)gmail.com
Target Milestone: ---
…
[View More]Created attachment 1048
--> https://bugs.openldap.org/attachment.cgi?id=1048&action=edit
config.ldif
2.6.9, symas-packaged RPMs, Rocky 9.
In slapacl, a rootDN user is, as you'd expect, allowed to do anything:
# /opt/symas/sbin/slapacl -D 'cn=Manager,dc=example,dc=com' -u -b
'uid=fakeuser,ou=users,dc=example,dc=com' entry/write
authcDN: "cn=manager,dc=example,dc=com"
write access to entry: ALLOWED
But, a user given full-manage rights, segfaults:
# /opt/symas/sbin/slapacl -D 'uid=direct,ou=users,dc=example,dc=com' -u -b
'uid=fakeuser,ou=users,dc=example,dc=com' entry/write
authcDN: "uid=direct,ou=users,dc=example,dc=com"
Segmentation fault (core dumped)
Traceback:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0,
flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at
./../../../libraries/liblmdb/mdb.c:2893
2893 flags |= env->me_flags & MDB_WRITEMAP;
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.34-60.el9.x86_64 libevent-2.1.12-6.el9.x86_64
sqlite-libs-3.34.1-6.el9_1.x86_64
(gdb) bt
#0 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0,
flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at
./../../../libraries/liblmdb/mdb.c:2893
#1 0x00007ffff71361a1 in mdb_opinfo_get (op=op@entry=0x7fffffffdce0,
mdb=mdb@entry=0x7ffff7048010, rdonly=rdonly@entry=1,
moip=moip@entry=0x7fffffffc410)
at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:793
#2 0x00007ffff7136459 in mdb_entry_get (op=0x7fffffffdce0, ndn=0x7fffffffc640,
oc=0x5555557a4360, at=0x5555557c3560, rw=0, ent=0x7fffffffc4c8)
at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:620
#3 0x00005555555a77a0 in be_entry_get_rw (e=0x7fffffffc4c8, rw=0,
at=0x5555557c3560, oc=0x5555557a4360, ndn=0x7fffffffc640, op=0x7fffffffdce0)
at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1438
#4 fe_acl_group (op=0x7fffffffdce0, target=<optimized out>,
gr_ndn=0x7fffffffc640, op_ndn=0x7fffffffde10, group_oc=0x5555557a4360,
group_at=0x5555557c3560)
at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1494
#5 0x000055555559ec5c in backend_group (op=0x7fffffffdce0, target=<optimized
out>, gr_ndn=<optimized out>, op_ndn=<optimized out>, group_oc=<optimized out>,
group_at=<optimized out>)
at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1690
#6 0x00005555555bfbc2 in slap_acl_mask (access=ACL_WRITE,
state=0x7fffffffc660, count=1, matches=0x7fffffffcab0, val=<optimized out>,
desc=<optimized out>, e=0x7fffffffd910, op=0x7fffffffdce0,
mask=<synthetic pointer>, prev=0x0, a=0x5555557c3970) at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:1643
#7 slap_access_allowed (op=op@entry=0x7fffffffdce0, e=e@entry=0x7fffffffd910,
desc=<optimized out>, val=<optimized out>, access=<optimized out>,
state=<optimized out>, maskp=<optimized out>)
at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:288
#8 0x00005555555c1e2e in fe_access_allowed (op=0x7fffffffdce0,
e=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized
out>, state=<optimized out>, maskp=0x7fffffffd828)
at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:352
#9 0x00005555555b7c74 in access_allowed_mask (op=0x7fffffffdce0,
e=0x7fffffffd910, desc=0x55555573d540, val=<optimized out>, access=ACL_WRITE,
state=0x0, maskp=0x7fffffffd900)
at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:456
#10 0x0000555555620182 in slapacl (argc=<optimized out>, argv=0x7fffffffe398)
at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/slapacl.c:362
#11 0x000055555557658f in main (argc=<optimized out>, argv=<optimized out>) at
/usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/main.c:540
I could understand it if it was a case of "trying to verify cn/write and not
knowing if the user was objectClass=person" but for entry/write I don't see any
reason these should be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10274
Issue ID: 10274
Summary: Replication issue on MMR configuration
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: falgon.comp(a)gmail.com
Target Milestone: ---
Created …
[View More]attachment 1036
--> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit
In this attachment you will find 2 openldap configurations for 2 instances +
slamd conf exemple + 5 screenshots to show the issue and one text file to
explain what you see
Hello we are openning this issue further to the initial post in technical :
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Issue :
We are working on a project and we've come across an issue with the replication
after performance testing :
*Configuration :*
RHEL 8.6
OpenLDAP 2.5.14
*MMR-delta *configuration on multiple servers attached
300,000 users configured and used for tests
*olcLastBind: TRUE*
Use of SLAMD (performance shooting)
*Problem description:*
We are currently running performance and resilience tests on our infrastructure
using the SLAMD tool configured to perform BINDs and MODs on a defined range of
accounts.
We use a load balancer (VIP) to poll all of our servers equally. (but it is
possible to do performance tests directly on each of the directories)
With our current infrastructure we're able to perform approximately 300
MOD/BIND/s. Beyond that, we start to generate delays and can randomly come
across one issue.
However, when we run performance tests that exceed our write capacity, our
replication between servers can randomly create an incident with directories
being unable to catch up with their replication delay.
The directories update their contextCSNs, but extremely slowly (like freezing).
From then on, it's impossible for the directories to catch again. (even with no
incoming traffic)
A restart of the instance is required to perform a full refresh and solve the
incident.
We have enabled synchronization logs and have no error or refresh logs to
indicate a problem ( we can provide you with logs if necessary).
We suspect a write collision or a replication conflict but this is never write
in our sync logs.
We've run a lot of tests.
For example, when we run a performance test on a single live server, we don't
reproduce the problem.
Anothers examples: if we define different accounts ranges for each server with
SALMD, we don't reproduce the problem either.
If we use only one account for the range, we don't reproduce the problem
either.
______________________________________________________________________
I have add some screenshots on attachement to show you the issue and all the
explanations.
______________________________________________________________________
*Symptoms :*
One or more directories can no longer be replicated normally after performance
testing ends.
No apparent error logs.
Need a restart of instances to solve the problem.
*How to reproduce the problem:*
Have at least two servers in MMR mode
Set LastBind to TRUE
Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple
SLAMD test on same time for each server with the same account range.
Exceed the maximum write capacity of the servers.
*SLAMD configuration :*
authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \
--useSSL --trustStorePath ${CACERTJKS} \
--trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \
--bindPassword ${BINDPW} --baseDN "${BASEDN}" \
--filter "(uid=[${RANGE}])" --credentials ${USERPW} \
--warmUpIntervals ${WARMUP} \
--numThreads ${NTHREADS} ${ARGS}
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10266
Issue ID: 10266
Summary: Adopt broader RFC4511 NoD interpretation on lloadd's
client side
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)…
[View More]mistotebe.net
Target Milestone: ---
Server side, lloadd has long implemented a broad interpretation of NoD
unsolicited response handling: when the message is issued, no new requests are
accepted on the session however the client and server are both free to keep the
session open if there are any operations that have not resolved yet. The server
is still expected to close the connection as soon as no operations are still
pending.
This seems to interoperate with known clients. Those that want to will close
the session immediately, unaware of this possibility, those that also want to
interpret RFC 4511 this way can choose to wait for existing operations to
resolve.
This ticket is to track the lloadd's implementation of the client side of this
- when receiving a NoD message, we don't close the connection
immediately+unconditionally either but are willing to wait.
Related functionality:
- if connection was a bind connection processing a multi-stage SASL bind, the
bind should fail if/when the client attempts to progress it
- clients assigned to this connection through coherence at least 'connection'
are also marked closing
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10024
Issue ID: 10024
Summary: MDB_PREVSNAPSHOT broken
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: markus(a)objectbox.io
Target Milestone: ---
It seems that the patch #…
[View More]9496 had a negative side effect on MDB_PREVSNAPSHOT.
In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd
latest) commit is not selected. Instead, reads show that the latest commit was
selected voiding the effect of MDB_PREVSNAPSHOT.
I observed this in our test cases a while back. Today, I was finally able to
reproduce it and debug into it.
When creating the transaction to read the data, I debugged into mdb_txn_renew0.
Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0
(!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting
the first (index 0) meta page inside mdb_txn_renew0:
meta = env->me_metas[txn->mt_txnid & 1];
This line occurs twice (once for read txn and once for write txn; it affects
both txn types).
Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50.
It's only correct if the first meta page (index 0) is the older one.
I believe that this is related to #9496 because the patch, that was provided
there, removed the initialization of "env->me_txns->mti_txnid" in
mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was
set to 0.
I can confirm that adding back the following two lines back in fixes
MDB_PREVSNAPSHOT:
if (env->me_txns)
env->me_txns->mti_txnid = meta.mm_txnid;
The said patch including the removal of these two lines was applied in the
commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21).
I hope this information is useful to find a suitable fix. Please let me know if
you have questions. Also, I'd be happy to help confirming a potential fix with
our test suite.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10265
Issue ID: 10265
Summary: Make it possible to change olcBkLloadListen at runtime
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 …
[View More]Milestone: ---
Currently, olcBkLloadListen changes only take effect on lloadd startup:
- an added olcBkLloadListen should come online at the end of the modify
operation
- at the end of the modify operation a removed olcBkLloadListen will stop
listening on the sockets associated with it, clients that connected over these
are marked CLOSING
- to facilitate replacing a value where URIs resolved sockets overlap,
olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass
Lloadd's startup was modelled upon slapd's, but the requirements have changed
considerably when it was turned into a module. Sockets are acquired at module
configuration time, which is much later than standalone/slapd's own startup and
so the way the URLs are handled also needs to be reworked. This will resolve
other related issues.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog …
[View More]with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10279
Issue ID: 10279
Summary: add debug notice also to client tools
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: rossi.f(a)inwind.it
Target Milestone: ---
…
[View More]Created attachment 1040
--> https://bugs.openldap.org/attachment.cgi?id=1040&action=edit
openldap-2.6.4-debug-notice.patch
The command line -d option, when used for debugging, does nothing if openldap
was not compiled byth --enable-debug option. For the server part there is a
notice to the user regarding this, I propose to add the same also to client
tools.
Here is attached the simple patch.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10302
Issue ID: 10302
Summary: Double free of idcursor
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: simon.rupf(a)lzlabs.com
Target Milestone: ---
Created attachment …
[View More]1050
--> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit
proposed patch, which was created from current master, but also applies to
2.6.6
While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP
samples started causing a double free error at the end of the slapadd run.
While I can't share the LDIF in question and it didn't consistently cause the
issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and
suggest the attached patch that resolves that error to re-occur. I validated
the patch still applies to the current master branch of openldap, as well as to
2.6.6 on EL9 where we encountered this.
The error originally observed was this (commands being run as ldap user):
[...]
rm -r /var/lib/ldap
mkdir /var/lib/ldap
slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
-#################### 100.00% eta none elapsed 03s spd 4.2 M/s
Closing DB...double free or corruption (!prev)
Under valgrind, the following trace could be observed:
valgrind --vgdb=full --leak-check=full --show-leak-kinds=all
--track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502== Memcheck, a memory error detector
==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502==
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
==502== Invalid read of size 8
==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764)
==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202)
==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152)
==502== by 0x1D8291: slapadd (slapadd.c:511)
==502== by 0x1348C6: main (main.c:540)
==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd
==502== at 0x4847B4C: free (vg_replace_malloc.c:989)
==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638)
==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640)
==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066)
==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069)
==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962)
==502== by 0x1D8440: slapadd (slapadd.c:502)
==502== by 0x1348C6: main (main.c:540)
==502== Block was alloc'd at
==502== at 0x484482F: malloc (vg_replace_malloc.c:446)
==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690)
==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707)
==502== by 0x1D8150: slapadd (slapadd.c:453)
==502== by 0x1348C6: main (main.c:540)
[...]
Please advise if I can provide any further diagnostics, while I can still
relatively easily reproduce the issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10290
Issue ID: 10290
Summary: Combination of syncrepl+rwm+syncprov frees the wrong
modlist
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)…
[View More]mistotebe.net
Target Milestone: ---
An MPR setup with rwm enabled (regardless of configuration it seems) will crash
with the provided modlist being freed twice. This is the sequence of events of
what is stored in op->orm_modlist, allocated and freed by whom, replacing the
actual pointers to make it easier to track:
syncrepl_message_to_op: preparing a modify with 0xoriginal
syncrepl_op_modify: old modlist 0xoriginal replacing with 0xsyncrepl_op_modify
rwm_op_modify: old modlist 0xsyncrepl_op_modify replacing with 0xrwm_op_modify
<modify happens>
syncrepl_modify_cb: freeing 0xsyncrepl_op_modify, replacing with 0xoriginal
(forgetting 0xrwm_op_modify)
rwm_op_rollback: freeing 0xoriginal replacing with 0xsyncrepl_op_modify
syncrepl_message_to_op: went in with 0xoriginal, got 0xsyncrepl_op_modify back
syncrepl_message_to_op: freeing 0xsyncrepl_op_modify
Not sure who is at fault: syncrepl_modify_cb is the one freeing the wrong
modlist, but then if backover were to work with an actual "stack", running
response callbacks in the opposite order from the request, things would have
been ok too.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10229
Issue ID: 10229
Summary: ldap_result, when invoked with MSG_RECEIVED and a
timeout value set to 0 (polling), does not return all
available messages until it is called again
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: --…
[View More]-
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The issue is noticeable when ldap_result is used by the proxy back-ends. It has
not affected back-meta behavior, because when a first call is unsuccessful, it
retries with a small timeout. back-asyncmeta will also usually call it twice on
the same connection from different threads, although this is not a desired
behavior.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]