openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

[Issue 10254] New: Allow upgrading password hash on bind
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10254 Issue ID: 10254 Summary: Allow upgrading password hash on bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: me(a)floriswesterman.nl Target Milestone: --- Many OpenLDAP installations are likely to contain relatively old password hashes such as SSHA and CRYPT, as modern alternatives such as Argon are only recent additions. Due to the nature of password hashes, it is of course not possible to "unhash" the old values and rehash them with a more modern algorithm. The presence of these old password hashes poses a liability in case of information leaks or hacks. Currently, the only way to upgrade a password hash is to wait for the user to change their password. This can be sped up by expiring passwords and forcing users to change them. However, this can be slow and frequent password rotation is no longer considered a best practice. It would be a very helpful addition to add support for upgrading a password hash on bind. This is implemented in the 389 directory server: https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html Essentially, when a user binds, the password is checked like normal. In case of a successful bind, the proposed feature would check the hash algorithm used for the password; and in case it is not equal to the current `olcPasswordHash` value, the user-provided password is rehashed using the new algorithm and stored. This way, the old hashes are phased out more quickly, without being a disturbance to users. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=7981 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10254 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=7981 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/763 Gone with another auxiliary objectclass but rereading the conversation, I guess I'll adjust to use a subclass later. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10325] New: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10325 Issue ID: 10325 Summary: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The variant contrib overlay uses the wrong base OID for its attributes, which leads to OID duplication with DDS -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10327] New: Adding syncprov to cn=config can lock up server
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10327 Issue ID: 10327 Summary: Adding syncprov to cn=config can lock up server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- As reported on openldap-technical[0], adding syncprov to a cn=config DB can lock up the server. This happens when syncprov_db_otask is scheduled by syncprov_db_open. ITS#9045 has already dealt with this for config_back_entry_get, we can relax this description and allow a config_back_search do the same. Even though it is technically on a different thread than the main modification, AFAIK it is still the only one running as the server is paused and the main modification is paused waiting for it? [0]. 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 2

[Issue 10293] New: Log operations generated by syncrepl at STATS level
by openldap-its＠openldap.org 09 Apr '25

09 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10293 Issue ID: 10293 Summary: Log operations generated by syncrepl at STATS level Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Similarly to how incoming operations are logged, operations created by syncrepl should be logged as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10320] New: sigsegv in autogroup
by openldap-its＠openldap.org 08 Apr '25

08 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10320 Issue ID: 10320 Summary: sigsegv in autogroup Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sergej+openldap(a)p5n.pp.ru Target Milestone: --- slapd crashes in autogroup overlay on group modification I have few coredumps and can provide more information. This fails on 0x23 address, it may differs but it looks like f->f_un.f_un_complex is not ended with NULL sometimes. Modified group here is not autogroup, just groupOfUniqueNames. Operation is adding uniqueMember. Distro: Archlinux Overlay config: overlay autogroup autogroup-attrset labeledURIObject labeledURI uniqueMember autogroup-memberof-ad memberOf Stack: #0 0x00007e77bf511d7c in autogroup_memberOf_filter (f=f@entry=0x6f2c6d6165742d70, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1532 #1 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x6f2c6d6165742d70, f@entry=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1537 #2 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=0x5ac9490c2190) at autogroup.c:1537 #3 0x00007e77bf512538 in autogroup_modify_entry (op=<optimized out>, rs=0x7e7665cf9910) at autogroup.c:1606 #4 0x00005ac946faf432 in overlay_op_walk () #5 0x00005ac946faf5f2 in ?? () #6 0x00005ac946f494cf in fe_op_modify () #7 0x00005ac946f4b623 in do_modify () #8 0x00005ac946f304d7 in ?? () #9 0x00005ac946f30f4b in ?? () #10 0x00007e77c04756e1 in ldap_int_thread_pool_wrapper (xpool=0x5ac949016bc0) at tpool.c:1059 #11 0x00007e77bfe4b70a in start_thread (arg=<optimized out>) at pthread_create.c:448 #12 0x00007e77bfecfaac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (gdb) p *f Cannot access memory at address 0x23 (gdb) up #1 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x23, f@entry=0x55d1c45b6310, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) up #2 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x55d1c45b6310, f@entry=0x55d1c45b6670, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad ); (gdb) p *f->f_un.f_un_complex $5 = {f_choice = 124232868587560, f_un = {f_un_result = 939550768, f_un_desc = 0x70fd38006830, f_un_ava = 0x70fd38006830, f_un_ssa = 0x70fd38006830, f_un_mra = 0x70fd38006830, f_un_complex = 0x70fd38006830}, f_next = 0x23} f_next is 0x23 which is bad address -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10168] New: olcdbindex doesn't cleanup cleanly
by openldap-its＠openldap.org 01 Apr '25

01 Apr '25

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.

1 6

[Issue 10322] New: Retire 2.4 admin guide
by openldap-its＠openldap.org 01 Apr '25

01 Apr '25

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.

1 3

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

27 Mar '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 11

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