From: Kevin J. Menard, Jr. (no email)
Date: Wed Aug 08 2001 - 09:41:57 EDT
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
|
|
|