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=10322
Issue ID: 10322
Summary: Retire 2.4 admin guide
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
2.4 release stream has been dead for a while now however its Admin Guide is
still in place, we should remove it and possibly have links under it 301 to
admin26?
--
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=7901
requate(a)univention.de <requate(a)univention.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1059|0 |1
is obsolete| |
--
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.