Brian Cameron writes: > Darren/James: > > If multithread PAM is the right way to address these problems, then I am > all for working to get the multithread PAM module support code upstream into > GDM. I know this code is already in CDE login.
I'm not going to offer an opinion on multi-threaded PAM, because that's not the case under review, and I don't think we ought to be hashing out new designs on this list. (I will say, though, that I think the idea of "canceling" the password check because a fingerprint was offered -- as described in the bugzilla record -- is simply wrong. It shouldn't work that way because there's no good reason to believe that fingerprints are more secure than passwords.) My problem with the original fingerprint authentication case was not with internal design issues, such as whether the PAM user was single- or multi-threaded, but rather with the relationship between the biometric reader and the "workstation" (for lack of a better term) that the user is using. For keyboards, mice, and displays, I see an obvious way to relate them to a user approaching the system at a workstation. They're all attached to the same X server, and it's the X server's problem to make sure that these bits of hardware are associated with that one site. The biometric readers are coming at this sideways. There appears to be no way to know whether a given reader has anything to do with a given workstation. All that you can do is "guess," which seems a poor idea for something that aims to be a security system. I suspect that the underlying problem is that these devices are designed for a different environment -- the single-user Windows laptop. There are many things that make sense in such an environment that simply do not make sense on a larger multi-user system, and vice-versa. > It does seem that the PAM_MSG_NOCONF message type which doesn't expect > confirmation to be used only by thread #2 is a bit hacky. If you guys > tell me that this is really the right solution for solving this problem, > then I will put this code upstream into GDM. You can read more in the > bug report link above, note comment #5. I agree that the mt-PAM stuff seems a bit frightening. Perhaps Gary Winiger can comment here or offline. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
