https://bugs.openldap.org/show_bug.cgi?id=10168
Issue ID: 10168
Summary: olcdbindex doesn't cleanup cleanly
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: ---
if you run the following modify against slapd (notice the olcDbMultival data is
wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the
olcDbIndex changes:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: member eq
olcDbIndex: memberof eq
-
add: olcDbMultival
olcDbMultival: member,memberOf 5,15
-
--
You are receiving this mail because:
You are on the CC list for the issue.
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: ---
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.
https://bugs.openldap.org/show_bug.cgi?id=10270
Issue ID: 10270
Summary: Issues with pcache when refresh/persistPcache used
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Greetings, OpenLDAP-folk.
We've been running with the pcache overlay in 2.5.18
with both query refresh and pcachePersist for a bit
and have observed some oddities:
1.) Negative queries don't get refreshed
2.) Queries don't seem to be persisted
These behaviors are all exhibited from the current
git version as well - code/patches below for clarity
of communication:
Thanks!
Andy
commit c0b4fe92c8df746c0e6a777f93f1687135114eb9
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:43:47 2024 -0400
negative cache entries are not loaded when pcachePersist is on
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 9ef78fd6bf43..9fd72e6d7261 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -802,7 +802,11 @@ url2query(
goto error;
}
- cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 );
+ if (BER_BVISNULL( &uuid )) {
+ cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 );
+ } else {
+ cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 );
+ }
if ( cq != NULL ) {
cq->expiry_time = expiry_time;
cq->refresh_time = refresh_time;
commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:38:36 2024 -0400
queries with ttr/x-refresh are not loaded when pcachePersist is on
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 40c1f9673776..9ef78fd6bf43 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -749,7 +749,7 @@ url2query(
}
}
- if ( got != GOT_ALL ) {
+ if ( (got & GOT_ALL) != GOT_ALL) {
rc = 1;
goto error;
}
commit c7e52c90192a43876d40b9776a58db951d27937c
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:37:13 2024 -0400
ttr was not being applied to negatively cached entries
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 1d6e4ba4edcf..40c1f9673776 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -1580,6 +1580,8 @@ add_query(
case PC_NEGATIVE:
ttl = templ->negttl;
+ if ( templ->ttr )
+ ttr = now + templ->ttr;
break;
case PC_SIZELIMIT:
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10169
Issue ID: 10169
Summary: Add support for token only authentication with otp
overlay
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently the OTP overlay is password + token. It would be nice to be able to
configure it so it can run in a token only mode, similar to the slapo-totp
overlay in contrib. This would allow us to have a project supported solution
and retire that contrib module.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10313
Issue ID: 10313
Summary: 3-way multimaster oathHOTPCounter attribute update
code missing
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: agrru01(a)gmail.com
Target Milestone: ---
I posted on openldap technical mail list and got a response saying I should
file a feature request.
I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My
problem is that when authenticating with a user using HOTP, the attribute
oathHOTPCounter only updates the value on the target ldap instance. This means
the other two ldap instances do not get the updated HOTP-counter value and
therefore will allow authentication using the same HOTP code.
Interestingly enough, if I manually edit the oathHOTPCounter value it
synchronizes with the other masters.
Please see the technical mail list discussion:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10020
Issue ID: 10020
Summary: dynlist's @groupOfUniqueNames is considered only for
the first configuration line
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: msl(a)touk.pl
Target Milestone: ---
If we consider the following configuration of dynlist:
{0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames
{1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames
The {0} entry will correctly populate the memberOf relatively to static group
membership.
The {1} entry will produce dgMemberOf with dynamic group membership correctly
(based on memberURL query) but it will not populate static entries IF {0} entry
in configuration is present. IF I remove {0} from the dynlist configuration -
or - remove @groupOfUniqueNames part from this configuration line, then both
dynamic and static entries will be populated correctly for {1}.
So the effects are as follows on some user entry:
if both {0} and {1} are present - {1} produced only dynamic groups:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} -
{1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
If only {1} is present - {1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
For completness - if only {0} is present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
I would expect this behavior to be correct for the first case - {0} and {1}.
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9934
Issue ID: 9934
Summary: slapd-config(5) should document how to store
certificates for slapd usage
Product: OpenLDAP
Version: 2.5.13
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: ---
Commit 7b41feed83b expanded the ability of cn=config to save the certificates
used for TLS by slapd directly in the config database. However the
documentation for the new parameters was never added to the slapd-config(5) man
page.
olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
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: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
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 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.
https://bugs.openldap.org/show_bug.cgi?id=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
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: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.