Re: sasl easy config & install

Subject: Re: sasl easy config & install
From: Rob Siemborski (rjs3 at andrew dot cmu dot edu)
Date: Sat May 31 2003 - 13:00:02 EDT

On Fri, 30 May 2003, Jeremy Rumpf wrote:

> Would you be willing to help us figure out if there is a problem. I'd be more
> than happy to help and provide a fix. But I do need to be able to replicate
> the problem on my end to be able to fix it

This has been bothering me for quite some time now, and now I'm convinced
it's not saslauthd's fault at all.

When I looked into this today, I became totally convinced that saslauthd
is doing the right thing.

First, I ran against the pam_permit module for tens of thousands of
authentications with no leak, so that limited the possble sources to PAM
itself, or the pam_conv code. I then staticly allocated everything in the
pam_conv code, which resulted in segfaults when PAM tried to free it. So
I started looking at PAM.

It appears that Linux-PAM 0.75 (distributed by RedHat in both 8.0 and
9.0), is riddled with memory leaks (especially in pam_stack and pam_unix).

Looking through the bug list here:

Is quite surprising. However, there have been several memory leaks fixed
since 0.75, and I can't find any evidence of them being incorproated into
RedHat's local copy.

Specificly, I'm concrened about:
0.75: Memory leak in pam_unix (which has been fixed, but not in redhat's

pam_stack multiple memory leaks (still open)

This doesn't answer what might be going on with pam_ldap, but since
pam_permit works and our allocations in the conv function are as expected,
I can't accept blame for that either without a specific example of what is
going wrong. As we do supply an LDAP saslauthd module, no one should be
using pam_ldap anyway.

Apparently saslauthd is unique in being a long-running application that
uses PAM, I can't accept that no other long-running applications have
this problem.

Since bending over backwards to interoperate buggy code is often the way
to the dark side, I'm not about to do anything in the SASL code. For
users who have to deal with this, I'm going to suggest -n 0 (since the
only reason the other suggested patch works is that it relies on the fact
that eventually all cyrus processes will exit).


Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD