On Fri, Oct 23, 2009 at 02:24:48PM -0500, Douglas E. Engert wrote: > Nicolas Williams wrote: > >IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we > >have a [consolidation-private] pam_get_user() function, which IMO should > >also be Public. (b) was a good thing, and so was (c), but (c) is > >getting upset by modules that can prompt for PINs, or which can derive > >PAM_USER from smartcards and/or biometrics. > > PLEASE keep in mind that a PIN may be entered via a smartcard reader, > and will never be seen via the host. So a prompt for a PIN may not > have any input, just instructions. So one has to stop thinking about > PAM prompting.
Will's code does not issue prompts for PIN independently of the Kerberos code. If the PKINIT pre-auth plugin prompts for a PIN, then pam_krb5 will also, else it won't. Basically pam_krb5 will let krb5_get_init_creds*() to the work. That's not quite how it is today in S10 and OpenSolaris, because of the need to use PAM_AUTHTOK and because password aging prompting needs to not happen in pam_authenticate(3PAM). The password-based pre-auth will continue to work that way. > >I'm waiting for a code review from Gary to complete PSARC/2005/275. One > >possible way to solve the multi-layer negotiation issue would be to have > >pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from > >PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth > >sheme being tried. > > Another way might be to have prompt= parameter to pam_authtok_get, > set by the sysadmin. That's not really satisfactory. > >We've talked about this as well, and I think that too is out of scope > >here. But briefly, IMO there should be a way to select tokens for > >C_Login() in a way that takes PAM context (e.g., PAM_TTY) into > >consideration, so that only tokens that could be associated with a seat > >are used. > > Yes that is an issue on other OSes too. I'm sure it is.
