https://bugs.openldap.org/show_bug.cgi?id=9882
Issue ID: 9882 Summary: slapd crashes when lastbind enabled w/ multi-provider Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: smckinney@symas.com Target Milestone: ---
Created attachment 907 --> https://bugs.openldap.org/attachment.cgi?id=907&action=edit slapd.conf
Description: Crash during bind operation when lastbind's enabled in a multi-provider env.
Built from source: commit 23ef018c6f321413141f26ed6e1909f85047ba76 (HEAD -> OPENLDAP_REL_ENG_2_6, origin/OPENLDAP_REL_ENG_2_6)
Configuration: attached System: AlmaLinux8 Backtrace:
Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 749 on = oi->oi_list; [Current thread is 1 (Thread 0x7d6b1ffff700 (LWP 96272))] Missing separate debuginfos, use: yum debuginfo-install cyrus-sasl-lib-2.1.27-6.el8_5.x86_64 glibc-2.28-189.5.el8_6.x86_64 keyutils-libs-1.5.10-9.el8.x86_64 krb5-libs-1.18.2-14.el8.x86_64 libblkid-2.32.1-35.el8.x86_64 libcap-2.48-2.el8.x86_64 libcom_err-1.45.6-4.el8.x86_64 libdb-5.3.28-42.el8_4.x86_64 libgcc-8.5.0-10.1.el8_6.alma.x86_64 libmount-2.32.1-35.el8.x86_64 libselinux-2.9-5.el8.x86_64 libtool-ltdl-2.4.6-25.el8.x86_64 libuuid-2.32.1-35.el8.x86_64 libxcrypt-4.1.1-6.el8.x86_64 openssl-libs-1.1.1k-6.el8_5.x86_64 pcre2-10.32-2.el8.x86_64 systemd-libs-239-58.el8.x86_64 zlib-1.2.11-18.el8_5.x86_64 (gdb) bt #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 #1 0x00000000004e0135 in over_op_modify (op=0x7d6b1fffe690, rs=0x7d6b1fffe620) at backover.c:808 #2 0x000000000046d785 in fe_op_lastbind (op=0x7d6b1010ed40) at bind.c:503 #3 0x000000000046da7f in fe_op_bind_success (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:548 #4 0x000000000046d1e1 in fe_op_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:386 #5 0x000000000046c8cd in do_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:206 #6 0x000000000044427d in connection_operation (ctx=0x7d6b1fffea90, arg_v=0x7d6b1010ed40) at connection.c:1115 #7 0x000000000044488f in connection_read_thread (ctx=0x7d6b1fffea90, argv=0x16) at connection.c:1267 #8 0x00007f5f2d60a470 in ldap_int_thread_pool_wrapper (xpool=0xc79d80) at tpool.c:1053 #9 0x00007f5f2c1a51cf in start_thread () from /lib64/libpthread.so.0 #10 0x00007f5f2be11dd3 in clone () from /lib64/libc.so.6
https://bugs.openldap.org/show_bug.cgi?id=9882
--- Comment #1 from Michael Ströder michael@stroeder.com --- I've looked at the attached slapd.conf: Overlay order matters. I vaguely remember that syncprov overlay should be first in the stack (last in the config). At least that's how it works for Æ-DIR.
https://bugs.openldap.org/show_bug.cgi?id=9882
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to Michael Ströder from comment #1)
I've looked at the attached slapd.conf: Overlay order matters. I vaguely remember that syncprov overlay should be first in the stack (last in the config). At least that's how it works for Æ-DIR.
There are definitely issues with the config as far as items being in the wrong place generally, but syncprov is the first listed overlay on the stack. In 2.5+ lastbind functionality is built into slapd (as opposed to being the separate lastbind contrib overlay).
I would note that it's missing the lastbind precision setting which in a replicated environment is generally going to be necessary.
Regardless, I see no reason for a crash to occur.
https://bugs.openldap.org/show_bug.cgi?id=9882
--- Comment #3 from Shawn McKinney smckinney@symas.com ---
On Jul 10, 2022, at 3:04 PM, openldap-its@openldap.org wrote:
I would note that it's missing the lastbind precision setting which in a replicated environment is generally going to be necessary.
Adding and setting the precision to anything < than say 36000 (seconds), crashes slapd on next bind. That’s about the age of the env so must be as it’s trying to update an entry.
Here’s what’s in the log:
Jul 10 20:57:55 m02 slapd[228722]: connection_get(21): got connid=1000 Jul 10 20:57:55 m02 slapd[228722]: connection_read(21): checking for input on id=1000 Jul 10 20:57:55 m02 slapd[228722]: op tag 0x60, time 1657486675 Jul 10 20:57:55 m02 slapd[228722]: conn=1000 op=0 do_bind Jul 10 20:57:55 m02 slapd[228722]: >>> dnPrettyNormal: <dc=example,dc=com> Jul 10 20:57:55 m02 slapd[228722]: <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> Jul 10 20:57:55 m02 slapd[228722]: conn=1000 op=0 BIND dn="dc=example,dc=com" method=128 Jul 10 20:57:55 m02 slapd[228722]: do_bind: version=3 dn="dc=example,dc=com" method=128 Jul 10 20:57:55 m02 slapd[228722]: ==> mdb_bind: dn: dc=example,dc=com Jul 10 20:57:55 m02 slapd[228722]: conn=1000 op=0 BIND dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 Jul 10 20:57:55 m02 slapd[228722]: do_bind: v3 bind: "dc=example,dc=com" to "dc=example,dc=com" Jul 10 20:57:55 m02 slapd[228722]: => mdb_entry_get: ndn: "dc=example,dc=com" Jul 10 20:57:55 m02 slapd[228722]: => mdb_entry_get: oc: "(null)", at: "(null)" Jul 10 20:57:55 m02 slapd[228722]: mdb_dn2entry("dc=example,dc=com") Jul 10 20:57:55 m02 slapd[228722]: => mdb_dn2id("dc=example,dc=com") Jul 10 20:57:55 m02 slapd[228722]: <= mdb_dn2id: got id=0x1 Jul 10 20:57:55 m02 slapd[228722]: => mdb_entry_decode: Jul 10 20:57:55 m02 slapd[228722]: <= mdb_entry_decode Jul 10 20:57:55 m02 slapd[228722]: => mdb_entry_get: found entry: "dc=example,dc=com" Jul 10 20:57:55 m02 slapd[228722]: mdb_entry_get: rc=0 Jul 10 20:57:55 m02 slapd[228722]: fe_op_lastbind: old pwdLastSuccess value=20220710124823Z 29372s ago Jul 10 20:57:55 m02 slapd[228722]: daemon: activity on 1 descriptor Jul 10 20:57:55 m02 slapd[228722]: daemon: activity on:Jul 10 20:57:55 m02 slapd[228722]: Jul 10 20:57:55 m02 slapd[228722]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jul 10 20:57:55 m02 slapd[228722]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jul 10 20:57:55 m02 slapd[228722]: daemon: epoll: listen=9 active_threads=0 tvp=zero
Regardless, I see no reason for a crash to occur.
https://bugs.openldap.org/show_bug.cgi?id=9882
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.5.13
https://bugs.openldap.org/show_bug.cgi?id=9882
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS
--- Comment #4 from Howard Chu hyc@openldap.org --- Yeah, this was actually caused by the #9863 patch. https://git.openldap.org/openldap/openldap/-/merge_requests/549
https://bugs.openldap.org/show_bug.cgi?id=9882
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9863
https://bugs.openldap.org/show_bug.cgi?id=9882
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- head: • 4528bdb3 by Howard Chu at 2022-07-11T17:55:37+01:00 ITS#9882 bind: fix #9863 commit, use correct op/backend for mod
RE26:
• 4f7a8011 by Howard Chu at 2022-07-11T18:23:59+00:00 ITS#9882 bind: fix #9863 commit, use correct op/backend for mod
RE25:
• a88b31a8 by Howard Chu at 2022-07-11T18:24:06+00:00 ITS#9882 bind: fix #9863 commit, use correct op/backend for mod
https://bugs.openldap.org/show_bug.cgi?id=9882
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=9882
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED
https://bugs.openldap.org/show_bug.cgi?id=9882
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org