dovecot - Jul 2009 - 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-identity.html
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090722/bb9218cd/attachment-0002.bin>

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.