[Dovecot] PAM_USER falsely assumed immutable
In 1.2.1 there's:
passdb-pam.c:230 status = pam_get_item(pamh, PAM_USER, &item); passdb-pam.c:237 auth_request_set_field(request, "user", item, NULL);
so "item" is PAM_USER, which is then checked by auth_request_set_field:
1022 if (strcmp(request->user, value) != 0) { 1023 auth_request_log_debug(request, "auth", 1024 "username changed %s -> %s", 1025 request->user, value);
that it hasn't changed.
You're not allowed to assume that PAM_USER doesn't change. See, for example, http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/adg-security-user-id... to say nothing of the fact that Rutgers has PAM modules that do exactly that (change PAM_USER). This check needs to be relaxed (or, perhaps if you want a config directive for DontComplyWithThePAMSpec = true, you can have a tunable). Can this be as simple as ditching the call to auth_request_set_field, or is there concern over interactions between PAM and other auth features?
On Wed, 2009-07-22 at 14:04 -0400, Aaron Richton wrote:
In 1.2.1 there's:
passdb-pam.c:230 status = pam_get_item(pamh, PAM_USER, &item); passdb-pam.c:237 auth_request_set_field(request, "user", item, NULL);
so "item" is PAM_USER, which is then checked by auth_request_set_field:
1022 if (strcmp(request->user, value) != 0) { 1023 auth_request_log_debug(request, "auth", 1024 "username changed %s -> %s", 1025 request->user, value);
that it hasn't changed.
You're not allowed to assume that PAM_USER doesn't change.
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.
Do you have some PAM plugin that changes the username and you don't want it to be changed?
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.
participants (2)
-
Aaron Richton
-
Timo Sirainen