Hey Devdas,


Wednesday, August 08, 2001, 6:05:19 AM, you wrote:

DB> On Wed, 08 Aug 2001, David Wright spewed into the ether:
DB> <snip>
>> What exactly is the problem under consideration that (given the appropriate 
>> modules) PAM doesn't solve?

DB> Just one, IMHO. PAM needs root access. Not what I like. cyrus runs as a
DB> non root user. Kevin Menard has sent me a patch which will let cyrus
DB> contact ldap directly (from what I've understood of it, not looked very
DB> closely).

Ok, so you did get it.  Like I said, mostly just a port of the SASL patch
over, and it worked fine for me.  Btw, I'll be releasing a newer version of
the SASL LDAP patch later today.  Fixes a free() issue and removes the
default filter.

DB> If I may make a design suggestion, why not have authenticaion totally
DB> configurable? Let cmd_authenticate() take a parameter from the config
DB> file which specifies the login method.
DB> cmd_authenticate() will roughly look like
DB> cmd_authenticate(user,password,auth_type)
DB> {
DB> int result = -1;
DB> switch (auth_type) {
DB>         "ldap": result = auth_ldap();if (result != -1) break;
DB>         "pam" : result = auth_pam(); if (result != -1) break;
DB>         "sasl:   result = auth_sasl();if (result  != -1) break;
DB>         "default":break;        /*The user was not found here*/
DB> }; /* End switch */

DB> if (!result) return SUCCESS;
DB> else return FAILURE;
DB> };

DB> Each auth_*() function returns a -1, 1 or a 0, 0 for success and 1 for
DB> failure. User not found errors will be -1, allowing for fall through.

DB> This will make it easier to add modules for authenticating from any
DB> type of database.
DB> Does this concept of a factory type of function make sense?

I still say add all this to SASL.  That's what it's there for anyway, so you
don't need to hack imapd.c or pop3d.c everytime you want to add a new auth
method.  What I would like to see, is a way to dynamically add auth methods
to SASL.

-- 
 Kevin

Reply via email to