One simple stupid users trick owns all your bases ...

[Jeremy Allison]

On Fri, Sep 01, 2023 at 11:03:39AM -0700, Jeremy Allison via samba-technical wrote:
>On Fri, Sep 01, 2023 at 10:15:22AM -0700, Richard Sharpe wrote:
>>On Fri, Sep 1, 2023 at 10:04 AM Jeremy Allison <jra at samba.org> wrote:
>>>
>>>On Fri, Sep 01, 2023 at 09:21:09AM -0700, Richard Sharpe via samba-technical wrote:
>>>>Hi folks,
>>>>
>>>>I didn't follow the instructions carefully enough.
>>>>
>>>>I set up resolv.conf to point at 127.0.0.1 and an upstream nameserver
>>>>(10.20.1.100).
>>>>
>>>>During provisioning that created an entry of 'dns resolver = 127.0.0.1'.
>>>>
>>>>That resulted in the following crash. Looks like a bug.
>>>>
>>>>Provisioning should not use any of the aliases for the current system
>>>>as forwarders.
>>>>
>>>>In addition, perhaps the code should not crash if it gets a timeout.
>>>>
>>>>4.19.0rc4.
>>>
>>>Can you add a "panic action = /bin/sleep 99999999"
>>>and catch it in gdb. Knowing *exactly* what line
>>>it goes down on will help. A lot :-).
>>
>>OK:
>>
>>#0  0x00007fa0f256dd98 in nanosleep () from /lib64/libc.so.6
>>#1  0x00007fa0f256dc9e in sleep () from /lib64/libc.so.6
>>#2  0x00007fa0f8e1c13b in log_stack_trace () at ../../lib/util/fault.c:306
>>#3  0x00007fa0f8e1c33f in smb_panic_log (
>>   why=why at entry=0x7ffc3acd6050 "Signal 11: Segmentation fault")
>>   at ../../lib/util/fault.c:195
>>#4  0x00007fa0f8e1c4b3 in smb_panic (
>>   why=why at entry=0x7ffc3acd6050 "Signal 11: Segmentation fault")
>>   at ../../lib/util/fault.c:206
>>#5  0x00007fa0f8e1c619 in fault_report (sig=11) at ../../lib/util/fault.c:83
>>#6  sig_fault (sig=11) at ../../lib/util/fault.c:94
>>#7  <signal handler called>
>>#8  0x00007fa0f7b90049 in dns_cli_request_udp_done (subreq=<optimized out>)
>>   at ../../libcli/dns/dns.c:497
>>#9  0x00007fa0f7b9134d in dns_udp_request_done (subreq=0x618001b18900)
>>   at ../../libcli/dns/dns.c:157
>>#10 0x00007fa0f9764929 in tdgram_recvfrom_done (subreq=0x61800533cd00)
>>   at ../../lib/tsocket/tsocket.c:239
>>#11 0x00007fa0f976b1f7 in tdgram_bsd_recvfrom_handler (
>>   private_data=<optimized out>) at ../../lib/tsocket/tsocket_bsd.c:1186
>>#12 0x00007fa0f9769c18 in tdgram_bsd_fde_handler (ev=<optimized out>,
>>   fde=<optimized out>, flags=<optimized out>, private_data=<optimized out>)
>>   at ../../lib/tsocket/tsocket_bsd.c:910
>>#13 0x00007fa0f3dc53a7 in tevent_common_invoke_fd_handler ()
>
>tdgram_bsd_recvfrom_recv() calls tsocket_simple_int_recv()
>which should set:
>
>        case TEVENT_REQ_TIMED_OUT:
>                *perrno = ETIMEDOUT;
>                return -1;
>
>tdgram_recvfrom_done() looks like:
>
>static void tdgram_recvfrom_done(struct tevent_req *subreq)
>{
>        struct tevent_req *req = tevent_req_callback_data(subreq,
>                                 struct tevent_req);
>        struct tdgram_recvfrom_state *state = tevent_req_data(req,
>                                              struct tdgram_recvfrom_state);
>        ssize_t ret;
>        int sys_errno;
>
>        ret = state->ops->recvfrom_recv(subreq, &sys_errno, state,
>                                        &state->buf, &state->src);
>        if (ret == -1) {
>                tevent_req_error(req, sys_errno);
>                return;
>        }
>
>        state->len = ret;
>
>        tevent_req_done(req);
>}
>
>state->ops->recvfrom_recv() should be tdgram_bsd_recvfrom_recv()
>which should be returning -1 in the ETIMEDOUT Case.
>
>So it should never get to:
>
>lib/tsocket/tsocket.c:239
>
>:-(. Looking under gdb is the next step.

Did you find out what the cause of this one is ?

I lost the thread (sorry :-).

Jeremy.