On Wed, 22 Jul 2009, Timo Sirainen wrote:
I'm not really sure why you think that's wrong. The code is there exactly for the reason that if PAM changes username Dovecot will notice it and starts using it.
Actually, that makes a lot of sense. I was confusing other (proximate) logs with the implication that that situation resulted in the user being kicked out. That's not the case.
Do you have some PAM plugin that changes the username and you don't want it to be changed?
Yes, and history going back to Solaris 2.6 that applications -- even fairly paranoid ones like portable OpenSSH -- "respect" this. But honestly, all things considered, I'm not sure that this behavior isn't the better arrangement. It's worth a warning for history that Dovecot is presently the odd man out versus any PAM-enabled application I've ever seen (Solaris/Linux login, portable OpenSSH, ProFTPd, UW-IMAP, Apache's mod_auth_pam, xscreensaver, xdm/gdm, saslauthd, courier IMAP, I could go on forever) but it may well represent a better way moving forward.
Unless you have any other thoughts, I'll look at this from the PAM module development side (namely setting PAM_USER to the authorization target rather than authentication target), and speak up if there's any unforeseen consequences. The only situation that I can see getting interesting is if a module causes stack exit while the authentication target is still set. In practice, I don't think this will happen for a PAM_SUCCESS return, and I don't particularly care if there are additional red flags raised in a PAM_AUTH_ERR or other bad return.