Thomas,
Can you provide a reproducible case? e.g., does this happen on the first
authentication attempt after starting saslauthd (with the shadow backend),
or are there other factors at play that you can identify?
On 05/12/15 11:08 +0200, Thomas Kupka wrote:
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
_______________________________________________
Pkg-cyrus-sasl2-debian-devel mailing list
pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel
--
Dan White
BTC Broadband
Network Admin Lead
Ph 918.366.0248 (direct) main: (918)366-8000
Fax 918.366.6610 email: dwh...@olp.net
http://www.btcbroadband.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
