On Wed, 18 Jul 2001, Shila Ofek wrote: > I do not want an alternate store of account information. I want the logic > of the login procedure in OpenSSH to be like that of login. Meaning, I want > authentication to be done first, and after that (the radius and Tacacs > libraries replace the user to the template user) I want the SSH to perform > the getpw with the new user. > What I'm looking for are patched to this code, or alternate solutions that > work right, because the current implementation doesn't allow the proper use > of pam authorization with pam_tacacs and pam_radius, it only allows use of > authentication with pam_unix, and for that I don't need pam. It's a legitimate concern if an app calls getpwnam() before invoking PAM; there are PAM modules which will remap the applicant-supplied username to a corresponding Unix username as part of the authentication process, returning the true username of the authenticated user via the PAM_USER item. Running checks against the system password file before calling PAM can not only cause users considered valid by the PAM config to be rejected by OpenSSH, it can also cause applicants to gain access as users that they don't actually have the password for. For example, in a large organization, it's not out of the question that the password file and the map file would be maintained by different parties. A namespace collision between the two could cause someone logging in with username 'foo/bar', which is supposed to be mapped to 'foobar', to actually gain access as a completely different user 'foo/bar', unless the PAMified app checks the value of PAM_USER *after* running through the PAM authentication and authorization checks. It's a bit of an edge case right now, but pam_krb5 (at least) can already do this sort of mapping. If other modules follow suit, sooner or later I fear some admin will be left puzzling over a break-in. Steve Langasek postmodern programmer
