>Number:         30608
>Category:       bin
>Synopsis:       sshd doesn't honour PAM modules changing PAM_USER
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 27 07:17:00 +0000 2005
>Originator:     Luke Mewburn
>Release:        NetBSD 3.0_BETA
>Organization:
TNF
>Environment:
>Description:

	PAM modules may change the value of PAM_USER as part of a
	successful authentication.  This allows a user to login
	with one username but have the PAM module change that to
	local username (to be looked up in the system passwd(5)
	database) to provide the (traditional) UNIX user auth
	details.

	Examples include

	    *	a RADIUS module that accepts "user@somedomain.com"
		as the original username and maps that to
		a "template" user (e.g, "somedomain").

	    *	a Kerberos module that accepts "user@realm"
		and maps that to "user", whilst setting up
		the appropriate credential cache for "user@realm".

	This behaviour is acceptable in the "PAM way", at least as
	far as I have been able to determine, and other users of
	PAM (login, libtelnet, ...) correctly cope with this.

	sshd (from OpenSSH) doesn't cope with this; it assumes that
	the user name passed to PAM is the final one to authenticate
	with.

	As an aside: this issue in OpenSSH may be the cause of
	various problems that people have had in the past using
	OpenSSH on systems in conjunction with PAM & RADIUS.
	Unfortunately my (brief) research into this didn't reveal
	many more helpful details.


>How-To-Repeat:

	Write a simple PAM module that accepts logins as "foo" but
	maps that to the user "bar" using:
		(void)pam_set_item(pamh, PAM_USER, "bar");
		return PAM_SUCCESS;

	Attempt to ssh login as "foo" when there is not an existing
	user "bar".  (If there is an existing user "bar" it will
	most likely use the incorrect passwd(5) entry)


>Fix:

	Modify sshd to support changing the username (et al) of
	the authctxt after a successful login (PAM_SUCCESS) to the
	result of  pam_get_item(..., PAM_USER, &newuser);
	This appears non trivial because the change needs to work
	with and without privsep.