https://bugs.openldap.org/show_bug.cgi?id=10314
Issue ID: 10314
Summary: Only install the slapi-plugin.h header if building
slapi library
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: mattias.ellert(a)physics.uu.se
Target Milestone: ---
Created attachment 1054
--> https://bugs.openldap.org/attachment.cgi?id=1054&action=edit
Proposed patch
The slapi-plugin.h header does not make sense without the slapi library.
The attached patch makes the installation of the header conditional.
--
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=10312
Issue ID: 10312
Summary: olcSubordinate does not accept a 'false' keyword,
contrary to documentation
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gray(a)nxg.name
Target Milestone: ---
The slapd-config(5) manpage documents the olcSubordinate keyword as
olcSubordinate: [TRUE | FALSE | advertise]
If, however, I try to create a database using
olcSubordinate: false
then slapadd objects with
olcSubordinate: value #0: suffix "ou=foo,o=bar": subordinate must be "TRUE"
or "advertise".
(For the sake of completeness, it might be worth noting in the manpage that the
(unsurprising) default is for a search of a superior database _not_ to be
propagated to the subordinate one – ie, the presumed behaviour of
olcSubordinate:false)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10310
Issue ID: 10310
Summary: Update pbkdf2 overlay so iterations can be
configurable
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The pbkdf2 password hashing contrib overlay has the number of iterations hard
coded at 10,000. It would be helpful to update the module to allow this to be
configurable instead, as is done with other password hashing modules.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10305
Issue ID: 10305
Summary: pkg-config should be used to find cyrus-sasl
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hi(a)alyssa.is
Target Milestone: ---
Static libraries do not encode their dependencies, so dependencies have to be
discovered using pkg-config or another equivalent mechanism. OpenLDAP does not
use pkg-config to find cyrus-sasl, which means that even if a working static
cyrus-sasl library is available, it won't be used, because OpenLDAP's build
system won't know to link its dependency libraries.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10311
Issue ID: 10311
Summary: Work with IETF LDAP working group to update password
hashing mechanism RFC
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: ---
Work with the IETF ldap working group to update the RFC to make the suggested
hashing mechanism be what is currently "best practice" rather than a specific
hashing mechanism.
--
You are receiving this mail because:
You are on the CC list for the issue.
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 #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.
https://bugs.openldap.org/show_bug.cgi?id=10303
Issue ID: 10303
Summary: Web site still presents the 2.5 version as LTS
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
The OpenLDAP web site still indicates that the OpenLDAP 2.5 version is the LTS,
despite a mail announced on August 10, 2024 that starting from January 2025 teh
2.6 branch will be the LTS.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10309
Issue ID: 10309
Summary: Handle potential null pointers returned by ber_strdup
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: safecoding233(a)gmail.com
Target Milestone: ---
Created attachment 1052
--> https://bugs.openldap.org/attachment.cgi?id=1052&action=edit
fix patch
I added two null pointer checks for pointers returned by ber_strdup.
--
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.