Re: saslauthd/PAM

Subject: Re: saslauthd/PAM
From: Sean (picasso at madflower dot com)
Date: Fri May 30 2003 - 18:34:53 EDT

Just for the record, I gave up on saslauthd since A it seems to crash a
lot. and B it flat out doesnt work with my PAM modules and C I found a
much better way.

I got the hacks from Michael Bacon of Duke fame, and that worked
flawlessly first try with the sample-client and sample-server.

I don't know why those aren't included in the release, especially
considering the "way you are supposed to do it" is broken.
I understand the logic and reasoning behind saslauthd, I am not saying
adandon it, but I'm not sure it is necessary in this particular instance.
It adds another layer of obfuscation to the process and another place
where things can go screwy (and they obviously are at this point).

This in itself (well lack of documentation doesnt help either) is
creating enough headaches for system admins like me who WANT to use the
sasl libs but I was a half a day from totally dumping SASL altogether
before I got this to work.

What I am saying is that systems administrators are looking for STABLE
and easily adapatable things to fit in with their existing systems before
you can get people to adapt it.


On Sat, 24 May 2003, Jeremy Rumpf wrote:

> On Saturday 24 May 2003 01:53 pm, Sean wrote:
> > This might be related to the unix sockets issue or it maybe something else
> > unrelated If you need/want more information. Please let me know what I can
> > do. (This also may have been sent 2x and if it was I apologize.)
> >
> > saslauthd is crashing when trying to use the sample client/server set-up
> > to test out PAM. RH 9.0/SASL 2.1.13
> >
> > It works if I use the PAM unix modules to auth against, but when I use the
> > pam_afs (openafs) modules, it fails to auth me and it is crashing
> > saslauthd, seemingly randomly. It does not do this every time and the only
> > thing I am changing is the pam.d/sample file to see if it is a
> > configuration problem with the PAM modules themselves. I believe this
> > crashed with both the pam_unix and the pam_afs modules although for sure
> > it has with the latter.
> >
> > If you look at ths following log snippet where it crashed, you will notice
> > i typo'd sufficient for the PAM entry for password. =) I don't think that
> > is it but it might be related there are other places in the logs where you
> > get that error and it doesnt crash saslauthd.
> >
> > If you look at it just after that you see:
> > May 23 20:04:19 test-afs-1 sasl-sample-server: size read failed
> > just before it crashed and this DOESNT happen every time you see the PAM
> > misentry error occur. But you see the "size read failed" everytime before
> > saslauthd crashes.
> >
> > May 23 20:02:43 test-afs-1 saslauthd[12921]: do_auth : auth
> > failure: [user=omalleys] [service=sample] [realm=] [mech=pam]
> > May 23 20:02:43 test-afs-1 sasl-sample-server: Password verification
> > failed
> > May 23 20:04:19 test-afs-1 saslauthd[12917]: PAM pam_parse: expecting
> > return value; [...sufficent]
> > May 23 20:04:19 test-afs-1 pam_afs[12958]: server_exit : master
> > exited: 12917
> > May 23 20:04:19 test-afs-1 pam_afs[12917]: server_exit : master
> > exited: 12917
> > May 23 20:04:19 test-afs-1 sasl-sample-server: size read failed
> > May 23 20:04:19 test-afs-1 sasl-sample-server: Password verification
> > failed
> > May 23 20:04:55 test-afs-1 sasl-sample-server: cannot connect to saslauthd
> > server: No such file or directory
> Just built and tested saslauthd on RH9.0 using pam_unix (pam-0.75-32). Started
> saslauthd (saslauthd -a pam -d -n 10). Used testsaslauthd (./testsaslauthd
> -u jrumpf -p xxxxx -s login).
> saslauthd[27730] :rel_accept_lock : released accept lock
> saslauthd[27731] :get_accept_lock : acquired accept lock
> saslauthd[27730] :do_auth : auth success: [user=jrumpf]
> [service=login] [realm=] [mech=pam]
> saslauthd[27730] :do_request : response: OK
> was the response. Then I fired off 5 of them banging away at saslauthd (20000
> logins a peice) with the cache disabled. Saslauthd survived the attack. Did
> the same with half using a correct password, the other half using a bad
> password. Saslauthd survived as well.
> Perhaps it could be some interaction with pam_afs?
> Just throwing in some prelim testing...
> Cheers,
> Jeremy

Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD