openldap-bugs

openldap-bugs@openldap.org

20933 discussions

[Issue 10314] New: Only install the slapi-plugin.h header if building slapi library
by openldap-its＠openldap.org 28 Feb '25

28 Feb '25

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.

1 0

[Issue 10313] New: 3-way multimaster oathHOTPCounter attribute update code missing
by openldap-its＠openldap.org 28 Feb '25

28 Feb '25

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.

1 0

[Issue 10312] New: olcSubordinate does not accept a 'false' keyword, contrary to documentation
by openldap-its＠openldap.org 27 Feb '25

27 Feb '25

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.

1 0

[Issue 10310] New: Update pbkdf2 overlay so iterations can be configurable
by openldap-its＠openldap.org 26 Feb '25

26 Feb '25

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.

1 3

[Issue 10305] New: pkg-config should be used to find cyrus-sasl
by openldap-its＠openldap.org 25 Feb '25

25 Feb '25

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.

1 2

[Issue 10311] New: Work with IETF LDAP working group to update password hashing mechanism RFC
by openldap-its＠openldap.org 25 Feb '25

25 Feb '25

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.

1 2

[Issue 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 21 Feb '25

21 Feb '25

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.

1 7

[Issue 10303] New: Web site still presents the 2.5 version as LTS
by openldap-its＠openldap.org 20 Feb '25

20 Feb '25

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.

1 1

[Issue 10309] New: Handle potential null pointers returned by ber_strdup
by openldap-its＠openldap.org 20 Feb '25

20 Feb '25

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.

1 2

[Issue 10299] New: slapacl -u segfaults on nonexistent user
by openldap-its＠openldap.org 20 Feb '25

20 Feb '25

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.

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs