I have changed the backend to pam and had no segfaults for the last 3 days. Seem like only the shadow backend has this issue.
On Fri, May 8, 2015 at 9:10 AM, Thomas Kupka <itchy...@gmail.com> wrote: > > On Wed, 6 May 2015 09:10:15 -0500 Dan White <dwh...@olp.net> wrote: > > > Can you get a backtrace from the core dump, and debug output, e.g.: > > > > saslauthd -d -c -m /var/spool/postfix/ > > It does not seem that debug gives out any interesting information. Here > are the last lines from when the child processes died: > > saslauthd[19194] :do_auth : auth success: [user=thomas] > [service=imap] [realm=] [mech=shadow] > saslauthd[19194] :do_request : response: OK > saslauthd[19195] :rel_accept_lock : released accept lock > saslauthd[19193] :get_accept_lock : acquired accept lock > saslauthd[19193] :rel_accept_lock : released accept lock > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19193] :do_auth : auth failure: [user=noauth] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19193] :get_accept_lock : acquired accept lock > saslauthd[19194] :do_auth : auth failure: [user=spam] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19193] :rel_accept_lock : released accept lock > saslauthd[19193] :do_auth : auth failure: [user=test] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=info] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19193] :get_accept_lock : acquired accept lock > saslauthd[19193] :rel_accept_lock : released accept lock > saslauthd[19193] :do_auth : auth failure: [user=admin] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=administrator] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19193] :get_accept_lock : acquired accept lock > saslauthd[19193] :rel_accept_lock : released accept lock > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=postmaster] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=sales] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=support] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=webmaster] > [service=smtp] [realm=] [mech=shadow] [reason=Incorrect password] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=help] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=contact] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=office] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > saslauthd[19194] :do_auth : auth failure: [user=staff] > [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] > saslauthd[19194] :get_accept_lock : acquired accept lock > saslauthd[19194] :rel_accept_lock : released accept lock > > The failed authentication attempts are certainly malicious software trying > out default credentials but they seem to be handled normally. > > > This backend doesn't get used much these days. pam should functionally > > replace it. Does it also produce a segfault? > > I will try this. I have shadow backend running for about 10 years now and > never had this urge to change it. > > Thomas > > On Wed, May 6, 2015 at 4:10 PM, Dan White <dwh...@olp.net> wrote: > >> On 05/03/15 10:24 +0200, Thomas Kupka wrote: >> >>> Package: sasl2-bin >>> Version: 2.1.26.dfsg1-13 >>> Severity: important >>> File: /usr/sbin/saslauthd >>> >>> Dear Maintainer, >>> >>> since upgrading to Jessie, all saslauthd processes segfault on a >>> multiple daily basis: >>> >>> May 3 06:26:12 mail kernel: [22739.740552] saslauthd[763]: segfault at >>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so >>> [7faffd557000+19f000] >>> May 3 06:26:12 mail kernel: [22739.928344] saslauthd[739]: segfault at >>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so >>> [7faffd557000+19f000] >>> May 3 06:26:12 mail kernel: [22740.127304] saslauthd[760]: segfault at >>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so >>> [7faffd557000+19f000] >>> May 3 10:04:24 mail kernel: [35831.420577] saslauthd[761]: segfault at >>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so >>> [7faffd557000+19f000] >>> May 3 10:04:24 mail kernel: [35831.607218] saslauthd[762]: segfault at >>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so >>> [7faffd557000+19f000] >>> May 3 10:04:24 mail postfix/smtpd[17269]: warning: SASL authentication >>> failure: cannot connect to saslauthd server: Connection refused >>> >> >> Can you get a backtrace from the core dump, and debug output, e.g.: >> >> saslauthd -d -c -m /var/spool/postfix/var/run/saslauthd -a shadow >> >> I can't reproduce your segfault on my unstable system running >> 2.1.26.dfsg1-13. However, I'm several version behind on some of the linked >> libraries. >> >> -- Configuration Files: >>> /etc/default/saslauthd changed: >>> START=yes >>> DESC="SASL Authentication Daemon" >>> NAME="saslauthd" >>> MECHANISMS="shadow" >>> >> >> This backend doesn't get used much these days. pam should functionally >> replace it. Does it also produce a segfault? >> >> -- >> Dan White >> > > >
