On Mon, 2006-11-20 at 11:38 -0800, Frank Cusack wrote:
Looked into the source and I see that pam doesn't actually implement any caching. Also, default_pass_scheme is not initialized (apparently the cache can store multiple types [schemes] of passwords per key). So the example config using a cache_key cannot work.
Yes, the default_pass_scheme was missing. Guess I never actually tested if it worked.
I started working on implementing this, but I see that in src/auth/passdb-pam.c:pam_auth(), near the end, the PAM_USER is retrieved (nice, since PAM allows changing of the username but no one implements this) and then saved in the auth request with auth_request_set_field().
Now, what is the point of all that? This code runs in the child forked to do the PAM auth, and the username is not propagated to the parent (AFAICT). And setting this data in the auth request doesn't do anything, since this code runs in the child. (Or is the auth request data in shared memory? Doesn't look like it.)
Right. I'm not sure why I ever did that. Probably I wasn't thinking too much, or maybe back when I first implemented it the PAM code was running in the same process.
I didn't remove it anyway. I want to later make PAM lookups go through dovecot-auth worker processes the same way MySQL lookups are done now. After that the code will work since the username is sent back to the main process.