[Samba] bind9 failure when using dlz_bind

[Dale Schroeder]

On 7/1/24 11:16 AM, Rowland Penny via samba wrote:
> On Sat, 29 Jun 2024 12:11:32 -0500
> Samba via samba<samba at lists.samba.org>  wrote:
>
>> Michael,
>>
>> Thanks for doing the backtrace.  I would have needed a lot of
>> instruction.
>>
>> Dale
>>
>> On 06/28/2024 3:12 AM, Michael Tokarev via samba wrote:
>>> On 6/28/24 08:16, Douglas Bagnall wrote:
>>>
>>>> And yes, a backtrace will help.
>>>
>>> $ gdb /usr/sbin/named
>>> GNU gdb (Debian 13.2-1+b2) 13.2
>>>
>>> (gdb) ru -4 -d10 -n1 -f -p54 -L /dev/stdout
>>> Starting program: /usr/sbin/named -4 -d10 -n1 -f -p54 -L /dev/stdout
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> [New Thread 0x7ffff3b7f680 (LWP 546107)]
>>>
>>> Thread 1 "named" received signal SIGSEGV, Segmentation fault.
>>> 0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>
>>> (gdb) bt
>>> #0  0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> #1  0x00007ffff6f35669 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> #2  0x00007ffff6f37e2f in free () from
>>> /lib/x86_64-linux-gnu/libc.so.6 #3  0x00007ffff13e1155 in ?? ()
>>> from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
>>> #4  0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0,
>>> reference_ctx=0x7ffff4235d20) at
>>> source4/dsdb/schema/schema_set.c:896 #5  0x00007ffff13e0d5c in ??
>>> () from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
>>> #6  0x00007ffff463f2c2 in ldb_module_init_chain () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #7  0x00007ffff463f2c2 in ldb_module_init_chain () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #8  0x00007ffff143cdd4 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/samba/ldb/rootdse.so
>>> #9  0x00007ffff463f2c2 in ldb_module_init_chain () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #10 0x00007ffff1410f13 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/samba/ldb/samba_dsdb.so
>>> #11 0x00007ffff463f2c2 in ldb_module_init_chain () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #12 0x00007ffff463f3ac in ldb_load_modules () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #13 0x00007ffff463e2be in ldb_connect () from
>>> /lib/x86_64-linux-gnu/libldb.so.2
>>> #14 0x00007ffff2455435 in samba_ldb_connect
>>> (ldb=ldb at entry=0x7ffff4288fe0, lp_ctx=lp_ctx at entry=0x7ffff3cd8720,
>>>      url=url at entry=0x7ffff43fa960
>>> "/var/lib/samba/bind-dns/dns/sam.ldb", flags=flags at entry=64) at
>>> lib/ldb-samba/ldb_wrap.c:230
>>> #15 0x00007ffff321a678 in samdb_connect_url
>>> (mem_ctx=mem_ctx at entry=0x7ffff4277de0, ev_ctx=0x7ffff42b1720,
>>> lp_ctx=0x7ffff3cd8720,
>>>      session_info=0x7ffff3cd8a20, flags=64, flags at entry=0,
>>> url=url at entry=0x7ffff43fa960 "/var/lib/samba/bind-dns/dns/sam.ldb",
>>>      remote_address=0x0, ldb_ret=0x7ffff4277df0,
>>> errstring=0x7fffffff8be0) at source4/dsdb/samdb/samdb.c:96
>>> #16 0x00007ffff47aba6e in dlz_create (dlzname=<optimized out>,
>>> argc=1, argv=0x7ffff42ec288, dbdata=0x7ffff42776a8)
>>>      at source4/dns_server/dlz_bind9.c:741
>>> #17 0x0000555555579126 in ?? ()
>>> #18 0x00007ffff7b4f49a in ?? () from
>>> /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
>>> #19 0x00007ffff7a5b105 in dns_dlzcreate () from
>>> /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
>>> #20 0x000055555558cf07 in ?? ()
>>> #21 0x000055555559d88f in ?? ()
>>> #22 0x000055555559eb81 in ?? ()
>>> #23 0x00007ffff7c6e537 in isc.async_cb () from
>>> /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
>>> #24 0x00007ffff737cd33 in ?? () from
>>> /lib/x86_64-linux-gnu/libuv.so.1 #25 0x00007ffff7390a72 in ?? ()
>>> from /lib/x86_64-linux-gnu/libuv.so.1 #26 0x00007ffff737d9f8 in
>>> uv_run () from /lib/x86_64-linux-gnu/libuv.so.1 #27
>>> 0x00007ffff7c81850 in ?? () from
>>> /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
>>> #28 0x000055555556e97a in main ()
>>>
>>> (gdb) frame 3
>>> #3  0x00007ffff13e1155 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
>>>
>>> (gdb) frame 4
>>> #4  0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0,
>>> reference_ctx=0x7ffff4235d20) at
>>> source4/dsdb/schema/schema_set.c:896 896                schema_out
>>> = refresh_fn(loaded_from_module, (gdb) l
>>> 891            /* We need to guard against recursive calls here */
>>> 892            if (ldb_set_opaque(ldb, "dsdb_schema_refresh_fn",
>>> NULL) != LDB_SUCCESS) {
>>> 893                ldb_debug_set(ldb, LDB_DEBUG_FATAL,
>>> 894                          "dsdb_get_schema: clearing
>>> dsdb_schema_refresh_fn failed");
>>> 895            } else {
>>> 896                schema_out = refresh_fn(loaded_from_module,
>>> 897                            ldb_get_event_context(ldb),
>>> 898                            schema_in,
>>> 899                            use_global_schema);
>>> 900            }
>>>
>>> Smells like the stack is damaged..
>>
> OK, see bughttps://bugzilla.samba.org/show_bug.cgi?id=15643
>
> Where Michael Saxl has identified the problem and provided a workaround.
>
> Seemingly you need to set an environmental variable
> LDB_MODULES_DISABLE_DEEPBIND
>
> The easiest way I found to do this was to create a systemd override file
>
> systemctl edit named.service
>
> Add (where it tells you to):
>
> [Service]
> Environment="LDB_MODULES_DISABLE_DEEPBIND=1"
>
> Save and close the file.
>
> Now start Bind9
>
> systemctl start named.service
>
> It should work.
>
> Rowland
Thanks, Rowland.  It did work, although I can't say I know what I did - 
even after reading through the bug report. 🙂

Assuming this is eventually fixed, will the override file cause problems 
at that time?

Thanks, again.
Dale