[Dovecot] plain auth problem with beta4
Using kmail with PLAIN authentication worked fine with beta3 but trying it with beta4 authentication fails.
This is because kmail sends "username \0 username \0 password" in the authorization token and the new code to call auth_request_set_login_username() when supplied an authid must be returning failure (certainly commenting this code out returns to the beta3 behaviour of successfully authenticating). I had a quick look at the routine to see why it might be failing but didn't really work out what its supposed to do.
cheers mark
On Tuesday 04 April 2006 12:50, Mark Davies wrote:
Using kmail with PLAIN authentication worked fine with beta3 but trying it with beta4 authentication fails.
This is because kmail sends "username \0 username \0 password" in the authorization token and the new code to call auth_request_set_login_username() when supplied an authid must be returning failure (certainly commenting this code out returns to the beta3 behaviour of successfully authenticating). I had a quick look at the routine to see why it might be failing but didn't really work out what its supposed to do.
On re-reading the beta4 release announcement, kmail's usage is presumably conflicting with this new feature: + Added support for "master users" who can log in as other people. The master username can be given either in authorization ID string with SASL PLAIN mechanism or by setting auth_master_user_separator and giving it within the normal username string. Since that is dealing with logging in as someone else and for kmail the authorization ID and authentication ID are the same should be able to treat this case equivalently to if no authorization ID was given shouldn't we? --- mech-plain.c.orig 2006-04-05 15:01:25.000000000 +1200 +++ mech-plain.c 2006-04-05 15:04:16.000000000 +1200 @@ -58,7 +58,7 @@ /* invalid username */ auth_request_log_info(request, "plain", "%s", error); auth_request_fail(request); - } else if (*authid != '\0' && + } else if (*authid != '\0' && strcmp(authid, authenid) != 0 && !auth_request_set_login_username(request, authid, &error)) { /* invalid login username */ auth_request_log_info(request, "plain", cheers mark
On Tuesday 2006-April-04 22:06, Mark Davies wrote:
--- mech-plain.c.orig 2006-04-05 15:01:25.000000000 +1200 +++ mech-plain.c 2006-04-05 15:04:16.000000000 +1200
The patch worked. THANK YOU! :)
I was going crazy over this for 2 days. I've never had trouble with local users authenticating. I tried numerous different accounts with known good passwords, logged and verified the "printf 'username\0username\0password' | mmencode" string ... and pulled out clumps of hair.
Was this not an issue with other MUAs? If not, should the kmail developers be told about this?
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: headerOn Saturday 2006-April-08 03:37, I wrote:
On Tuesday 2006-April-04 22:06, Mark Davies wrote:
--- mech-plain.c.orig 2006-04-05 15:01:25.000000000 +1200 +++ mech-plain.c 2006-04-05 15:04:16.000000000 +1200
The patch worked. THANK YOU! :)
There does appear to be a broken feature, perhaps associated with the patch. With this example uncommented: # passdb passwd-file { # # File contains a list of usernames, one per line # args = /etc/dovecot.deny # deny = yes # } (and a /etc/dovecot.deny existing as described) I get a signal 11 at startup: Apr 8 04:45:04 wood dovecot: Dovecot v1.0.beta5 starting up Apr 8 04:45:05 wood dovecot: child 1024 (auth) killed with signal 11 Apr 8 04:45:05 wood dovecot: Auth process died too early - shutting down
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
participants (2)
-
/dev/rob0
-
Mark Davies