cyrus imap + pam

Michael Bacon baconm at
Sat Apr 19 21:27:06 EDT 2003

I haven't had time to investigate since the beginning of March when that 
bug was posted.  The added PAM support is working very well for us, and so 
I've been considering it a dead problem.  I'm going to be trying saslauthd 
again this summer, I think, but for now, you'll have to investigate it for 

CMU uses saslauthd+gssapi (I believe) with great success, if I'm not 
mistaken, so I believe it may be some sort of toxic circumstance that we 
were creating.  Nonetheless, we've found direct PAM support to cure our 
ills; it's my belief that direct PAM support is a much sounder design, but 
that's apparently not the belief of the cyrus folks.  Oh, well, we're all 
entiled... ;)


--On Friday, April 18, 2003 9:44 AM -0400 Etienne Goyer 
<etienne.goyer at> wrote:

> On Thu, Apr 17, 2003 at 08:13:24PM -0400, Michael Bacon wrote:
>> We, however, kept running into problems with saslauthd.  The gssapi
>> saslauthd was crashing on us, and the PAM saslauthd module did some
>> things  that broke the gssapi PAM module we wanted to use.  After a
>> while of  hacking on it trying to get it to behave, we just wrote pam
>> support back  into the thing.  I understand that the saslauthd in SASL
>> 2.1.13 has many  improvements, so this may be dated, but we've had much
>> better luck with the  direct pam support than we did with  saslauthd.
> According to the ChangeLog for cyrus-sasl-2.1.13, a memory/file
> descriptor leak had been fixed as of 2003-03-06.  Could the problem you
> mention be caused by these bug ?  I am worried because we will need to
> use saslauthd + gssapi and are expecting a pretty high load (a few
> thousands of connections per hour).  If not, did you pinned down the
> cause ?
> --
> Etienne Goyer                    Linux Québec Technologies Inc.
>       etienne.goyer at
> PGP Pub Key:
> Fingerprint: F569 0394 098A FC70 B572  5D20 3129 3D86 8FD5 C853

More information about the Info-cyrus mailing list