Re: [exim] 4.95-RC0 - SIGSEGV (maybe attempt to write to imm…

Inizio della pagina
Delete this message
Reply to this message
Autore: Matthew Frost
Data:  
To: Jeremy Harris via Exim-users
Oggetto: Re: [exim] 4.95-RC0 - SIGSEGV (maybe attempt to write to immutable memory) & other oddities
On Fri, Jul 23, 2021 at 04:35:57PM +0100, Jeremy Harris via Exim-users wrote:
> The best-quality info will be a coredump.
>
> Arranging one is hard as Exim is setuid. I've not tried
> on a BSD, but Linux requires some deliberate relaxation of security
> restrictions (setuid programs are carrying sensitive info; a
> dump file has that info, leaving dump files with such info
> lying around is obviously a major risk...)


This:

sysctl kern.sugid_coredump=1

seems to be the FreeBSD sysctl for enabling this.

> Compiling with debug flag (eg, for gcc / gdb, "-ggdb")
> before getting the dump would be good.
> Don't worry about debug versions of libraries.


I used -glldb and stopped the exim binary being stripped.

> Then "bt" in gdb will give us a file and line number.


So now I believe I've got the 12.2 (non-jailed) machine in a position
to get this (this was just me killing -11 it to test):

%sudo lldb /usr/exim/bin/exim-4.95-RC0-2 --core core.exim-4.95-RC0-2.40.55758.core 
(lldb) target create "/usr/exim/bin/exim-4.95-RC0-2" --core "core.exim-4.95-RC0-2.40.55758.core"
Core file '/var/spool/exim/core.exim-4.95-RC0-2.40.55758.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'exim-4.95-RC0-2', stop reason = signal SIGSEGV
  * frame #0: 0x0000000800a418da libc.so.7`__sys_select + 10
    frame #1: 0x0000000800c8fcb2 libthr.so.3`___lldb_unnamed_symbol44$$libthr.so.3 + 66
    frame #2: 0x000000000025fd77 exim-4.95-RC0-2`daemon_go at daemon.c:2443:16 [opt]
    frame #3: 0x0000000000279d5e exim-4.95-RC0-2`main(argc=<unavailable>, cargv=<unavailable>) at exim.c:4947:3 [opt]
    frame #4: 0x0000000000254f00 exim-4.95-RC0-2`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7
(lldb) 


And I'll wait and see what happens (This machine did not SEGV like the
jailed one but might get some info from it if it fails again). It's
possible what I was seeing here was caused by the Jailed exim
malfunctioning…

> This might be something special about a FreeBSD jail.


Indeed.

I've asked the Jail Host, very nicely, if they'll set (temporarily)
the sysctls for me there. They might say "no", but there was no harm
in asking!

Fingers crossed,

Matthew