On Wed, 11 Nov 1998, Robert Watson wrote:

> > 	char *username, *password;
> > 	pam_get_user(pamhandle, "Log in you bastard", &username);
> > 	pam_get_item(pamhandle, PAM_AUTHTOK, &password);
> > 	auth_server_authenticate(username, password);
> 
> So, it depends what database is backing the authentication system.  Coda
> requires that it have a copy of the cleartext token in order to perform a
> shared-secret based binding.  In the standard UNIX password file, the
> password is irreversibly encrypted, and unless you have shadowing, the
> encrypted password is publically available.  As such, the Auth server
> cannot use a standard UNIX password file as a source of secrets.

'password' is what the user has typed in to try and authenticate
themselves.

> On the other hand, as I believe Peter must be referring to, a PAM module
> can be written that runs on the Coda *client* and uses the ability to
> retrieve Coda tokens to authenticate the user to a local identity.

Oh yea, I think everyone else is thinking in this vein too :-)

OK, if you were thinking of having the auth server use PAM to do its
checking, that is an interesting thought, but it sounds like the auth
server is too tied into the auth database to be completely PAMifiable.

Perhaps if the auth database were abstracted enough to allow writing a PAM
module for it, then the auth server could use the auth database API
directly for decryption purposes, and then the actual "are they allowed to
connect" check goes through PAM, which might then call the pam_codadb
module as well as any other pam modules...

-- Elliot
"In film you will find four basic story lines. Man versus man, man
 versus nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg