Subject: Re: sasl easy config & install
From: Sean (picasso at madflower dot com)
Date: Sat May 31 2003 - 17:45:25 EDT
I see your points and they are well taken. =)
I only have two things:
Even in the event of failed callback situation, saslauthd should not be
crashing. I can see a failing auth maybe, but crash because it isnt
returning appropriate data??
How do i begin to debug this mess to figure out what is actually going on?
so instead of subjectively saying it could be this or that we know and I
can at the very least report the bug to the right group of people with
some data that points substantially in one direction or another.
On Sat, 31 May 2003, Jeremy Rumpf wrote:
> 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)
> > TEST CASES:
> > 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
> > PWCHECK_METHOD: PAM
> > (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 openafs.org 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:
> ftp://ftp.net.ohio- state.edu/pub/users/jrumpf/pamdirp-0.9.7.tar.gz
> 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.