[Dovecot] cache_key assertion error 1.0.beta8
I just added auth caching with pam, and I'm getting this error:
dovecot: [ID 107833 mail.error] auth(default): file passdb.c: line 178 (passdb_init): assertion failed: (passdb->passdb->default_pass_scheme != NULL || passdb->passdb->cache_key == NULL)
A google search turns up <http://www.dovecot.org/list/dovecot-cvs/2005-March/004117.html> which looks approx like this except the assertion above is in passdb.c.
Anyway, is this a known problem in 1.0.beta8? I've been reluctant to upgrade to the rc's due to all the problems.
-frank
On November 19, 2006 8:58:54 PM -0800 Frank Cusack <fcusack@fcusack.com> wrote:
I get the same problem with rc15, except that in 1.0.beta8, the error would appear just once. In rc15, it repeats once/second. I guess rc15 restarts dovecot-auth if it dies?
Here are my non-default dovecot.conf (1.0.rc15) settings:
disable_plaintext_auth = no ssl_disable = yes protocol imap { mail_plugins = dspam mail_plugin_dir = /usr/lib/dovecot/imap } protocol lda { mail_plugins = cmusieve sendmail_path = /usr/sbin/sendmail } auth_cache_size = 64
4 hours
auth_cache_ttl = 14400 auth default { mechanisms = plain passdb pam { args = cache_key=%u%r dovecot } userdb passwd { } user = root }
This is on Solaris 10U2/x86. thanks -frank
On November 19, 2006 11:59:50 PM -0800 Frank Cusack <fcusack@fcusack.com> 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.
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.)
I didn't want to continue with my work if I had a misunderstanding of how to set the cache data.
-frank
On November 20, 2006 11:38:30 AM -0800 Frank Cusack <fcusack@fcusack.com> wrote:
Here is my first go at fixing it. It almost works.
- cache is initialized correctly
- user password is cached correctly until ttl expires
Once the ttl expires, dovecot attempts to use the cached password to authenticate. This fails in my environment. Then (after trying PAM with the cached password, even though ttl has expired) dovecot prompts the user for the password, however it never sends the request to PAM.
Some combination of waiting and trying again gets it working again, I haven't quite figure that one out. Might be waiting for the ttl expiry on the second (failed) request.
I think the after-ttl-expiry problems are due to a broken cache implementation, not really a problem with my patch. But maybe I need to do something to clear the cache? I didn't see anything like that in passdb-passwd.c.
-frank
On November 20, 2006 1:53:59 PM -0800 Frank Cusack <fcusack@fcusack.com> wrote:
Nope, it was my fault.
a) I was saving the user's entered password in the cache, not the correct password as known to pam b) I didn't need to save it explicitly, this is done already. Saving it explicitly was refreshing the cache (with the wrong password), I think.
Here is a simpler patch which just initializes default_pass_scheme. Also I removed the code which allows changing of the username ... since that code runs in the child and does nothing AFAICT. Maybe that part of my patch is broken though.
works for me ...
-frank
On Mon, 2006-11-20 at 11:38 -0800, Frank Cusack wrote:
Yes, the default_pass_scheme was missing. Guess I never actually tested if it worked.
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.
participants (2)
-
Frank Cusack
-
Timo Sirainen