Re: sasl easy config & install

Subject: Re: sasl easy config & install
From: Jeremy Rumpf (jrumpf at heavyload dot net)
Date: Sat May 31 2003 - 17:37:25 EDT

On Saturday 31 May 2003 03:32 pm, Sean wrote:
> On Sat, 31 May 2003, Rob Siemborski wrote:
> > This has been bothering me for quite some time now, and now I'm convinced
> > it's not saslauthd's fault at all.
> If it was a PAM problem, then there is no way I could get the results I am
> getting for my test cases (see TEST CASES below), because the problem
> would be duplicated between test cases since they are using the same pam
> libs. Therefore I can only see it as a problem with the saslauthd
> mechanism (including communications) itself.
> This is kind of why I really don't like saslauthd. It seems to get away
> from the the whole concept of SASL and turns it into ASL =) because you
> are adding 2 more points of complexity to the the equation when you have
> to use saslauthd with PAM instead of using it as a pwcheck method.

So what do you do when you're running against the passwd database, or require
root privs? Then your SASL application will need root privs as well.

> SASL is (was?) encouraged to be extensible by design (isnt that the point
> of SASL?). The saslauthd/pwcheck methods were hacks and their use is
> strongly discouraged from everything that I have read over the past 5
> years. Thus writing a PAM method, seems like it would be a great idea and
> strongly encouraged by the maintainers.

To me it's about options. Saslauthd can broker auths between thread safe
applications and non thread safe applications for example (think MIT Krb).
Combine a threaded server with a linked in PAM method that utilizes pam_krb5
and collect the core dumps. As well as provide user level isolation. The
choice is yours based upon your needs.

> I thought saslauthd/pwcheck was supposed to be an easy way to support
> novel/non-standard authenication methods like if I wanted to store
> user/password information in an AIFF file. I don't see PAM as a
> "non-standard" authenication method.

Non-standard until you constantly need root privs.

> sasl <-> PAM
> 1 2 3 (3 points of complexity or 3 places to break/debug)
> you end up with
> sasl <-> saslauthd <-> PAM
> 1 2 3 4 5 (5 pts of complexity or 5 places to break/debug)
> Case #1
> using saslauthd
> (sasl <-> saslauthd <-> pam)
> -pam_afs does not work, it wont return a succesful authenication and
> saslauthd crashes after 4-5 attempts.
> -pam_unix does work

> Case #2
> (sasl <-> pam)
> -pam_afs works. no crashes, successful authenication.
> -pam_unix works.
> The same machine, with just the conf files changed.
> sasl 2.1.13, stock pam from RH 9.0 and stock afs from using
> sample-server and sample-client.

The problem could still be in the PAM libs. For instance, sometimes the PAM
modules fail to pass the application specific data pointer in struct pam_conv
when issuing callbacks back to the application. Applications that use the
pointer to relay password/user information dump out. Applications that don't
make us of it work just fine.

As a specific example:

PAM auth plugin for the iPlanet directory server. Since the plugin uses the
application specific data pointer pass through in PAM to keep track of which
user is being authed. PAM issued callbacks back into the plugin would core
dump because the pam_krb module in Solaris 8 never passed the pointer
through. It would always pass a NULL pointer back to the application instead
of the one initially supplied.

But on the same machine other users of the pam_krb module (login, etc) worked
without a hitch.

At least in your situation you had the code. I'm not 100% convinced that
Saslauthd is solely to fault for your situation. PAM can be just as flaky as
anything else in the authentication food chain.


Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD