<div dir="ltr"><div><div>Dan,<br><br></div>the only lead I could have is a correlation between peaks of failed login attempts (from malicious sources most likely, at a rate of precisely one attempt every 5 seconds) and the segfaults. Does this help?<br><br>extract from mail.log:<br>May 10 10:17:50 mail cyrus/pop3[23539]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed<br>May 10 10:17:55 mail cyrus/pop3[23540]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed<br>May 10 10:18:00 mail cyrus/pop3[23541]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed<br><br></div>extract from messages:<br>May 10 10:18:09 mail kernel: [641457.138137] saslauthd[18768]: segfault at 0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in <a href="http://libc-2.19.so">libc-2.19.so</a>[7fdf75137000+19f000]<br>May 10 10:18:14 mail kernel: [641461.917719] saslauthd[18773]: segfault at 0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in <a href="http://libc-2.19.so">libc-2.19.so</a>[7fdf75137000+19f000]<br>May 10 10:18:19 mail kernel: [641466.650182] saslauthd[18764]: segfault at 0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in <a href="http://libc-2.19.so">libc-2.19.so</a>[7fdf75137000+19f000]<br><div><br></div><div>After this peak was over, there have been no more segfaults for the next 8 hours.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 3:42 PM, Dan White <span dir="ltr"><<a href="mailto:dwhite@olp.net" target="_blank">dwhite@olp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thomas,<br>
<br>
Can you provide a reproducible case? e.g., does this happen on the first<br>
authentication attempt after starting saslauthd (with the shadow backend),<br>
or are there other factors at play that you can identify?<div><div class="h5"><br>
<br>
On 05/12/15 11:08 +0200, Thomas Kupka wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have changed the backend to pam and had no segfaults for the last 3 days.<br>
Seem like only the shadow backend has this issue.<br>
<br>
On Fri, May 8, 2015 at 9:10 AM, Thomas Kupka <<a href="mailto:itchy.de@gmail.com" target="_blank">itchy.de@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, 6 May 2015 09:10:15 -0500 Dan White <<a href="mailto:dwhite@olp.net" target="_blank">dwhite@olp.net</a>> wrote:<br>
<br>
> Can you get a backtrace from the core dump, and debug output, e.g.:<br>
><br>
> saslauthd -d -c -m /var/spool/postfix/<br>
<br>
It does not seem that debug gives out any interesting information. Here<br>
are the last lines from when the child processes died:<br>
<br>
saslauthd[19194] :do_auth : auth success: [user=thomas]<br>
[service=imap] [realm=] [mech=shadow]<br>
saslauthd[19194] :do_request : response: OK<br>
saslauthd[19195] :rel_accept_lock : released accept lock<br>
saslauthd[19193] :get_accept_lock : acquired accept lock<br>
saslauthd[19193] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19193] :do_auth : auth failure: [user=noauth]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19193] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=spam]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19193] :rel_accept_lock : released accept lock<br>
saslauthd[19193] :do_auth : auth failure: [user=test]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=info]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19193] :get_accept_lock : acquired accept lock<br>
saslauthd[19193] :rel_accept_lock : released accept lock<br>
saslauthd[19193] :do_auth : auth failure: [user=admin]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=administrator]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19193] :get_accept_lock : acquired accept lock<br>
saslauthd[19193] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=postmaster]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=sales]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=support]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=webmaster]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Incorrect password]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=help]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=contact]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=office]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
saslauthd[19194] :do_auth : auth failure: [user=staff]<br>
[service=smtp] [realm=] [mech=shadow] [reason=Invalid username]<br>
saslauthd[19194] :get_accept_lock : acquired accept lock<br>
saslauthd[19194] :rel_accept_lock : released accept lock<br>
<br>
The failed authentication attempts are certainly malicious software trying<br>
out default credentials but they seem to be handled normally.<br>
<br>
> This backend doesn't get used much these days. pam should functionally<br>
> replace it. Does it also produce a segfault?<br>
<br>
I will try this. I have shadow backend running for about 10 years now and<br>
never had this urge to change it.<br>
<br>
Thomas<br>
<br>
On Wed, May 6, 2015 at 4:10 PM, Dan White <<a href="mailto:dwhite@olp.net" target="_blank">dwhite@olp.net</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/03/15 10:24 +0200, Thomas Kupka wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Package: sasl2-bin<br>
Version: 2.1.26.dfsg1-13<br>
Severity: important<br>
File: /usr/sbin/saslauthd<br>
<br>
Dear Maintainer,<br>
<br>
since upgrading to Jessie, all saslauthd processes segfault on a<br>
multiple daily basis:<br>
<br>
May 3 06:26:12 mail kernel: [22739.740552] saslauthd[763]: segfault at<br>
0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a><br>
[7faffd557000+19f000]<br>
May 3 06:26:12 mail kernel: [22739.928344] saslauthd[739]: segfault at<br>
0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a><br>
[7faffd557000+19f000]<br>
May 3 06:26:12 mail kernel: [22740.127304] saslauthd[760]: segfault at<br>
0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a><br>
[7faffd557000+19f000]<br>
May 3 10:04:24 mail kernel: [35831.420577] saslauthd[761]: segfault at<br>
0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a><br>
[7faffd557000+19f000]<br>
May 3 10:04:24 mail kernel: [35831.607218] saslauthd[762]: segfault at<br>
0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in <a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a><br>
[7faffd557000+19f000]<br>
May 3 10:04:24 mail postfix/smtpd[17269]: warning: SASL authentication<br>
failure: cannot connect to saslauthd server: Connection refused<br>
<br>
</blockquote>
<br>
Can you get a backtrace from the core dump, and debug output, e.g.:<br>
<br>
saslauthd -d -c -m /var/spool/postfix/var/run/saslauthd -a shadow<br>
<br>
I can't reproduce your segfault on my unstable system running<br>
2.1.26.dfsg1-13. However, I'm several version behind on some of the linked<br>
libraries.<br>
<br>
-- Configuration Files:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/etc/default/saslauthd changed:<br>
START=yes<br>
DESC="SASL Authentication Daemon"<br>
NAME="saslauthd"<br>
MECHANISMS="shadow"<br>
<br>
</blockquote>
<br>
This backend doesn't get used much these days. pam should functionally<br>
replace it. Does it also produce a segfault?<br>
<br>
--<br>
Dan White<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote></blockquote>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
Pkg-cyrus-sasl2-debian-devel mailing list<br>
<a href="mailto:Pkg-cyrus-sasl2-debian-devel@lists.alioth.debian.org" target="_blank">Pkg-cyrus-sasl2-debian-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Dan White<br>
BTC Broadband<br>
Network Admin Lead<br>
Ph <a href="tel:918.366.0248" value="+19183660248" target="_blank">918.366.0248</a> (direct) main: <a href="tel:%28918%29366-8000" value="+19183668000" target="_blank">(918)366-8000</a><br>
Fax <a href="tel:918.366.6610" value="+19183666610" target="_blank">918.366.6610</a> email: <a href="mailto:dwhite@olp.net" target="_blank">dwhite@olp.net</a><br>
<a href="http://www.btcbroadband.com" target="_blank">http://www.btcbroadband.com</a><br>
</font></span></blockquote></div><br></div>