Darren J Moffat wrote: > Douglas E. Engert wrote: >>> I really strongly dislike the idea of having a special password that >>> causes >>> it to behave differently. It just smells like a bad hack. >> >> Yes, it is a hack, based on the current pam limitations of only prompting >> for user and password. A more flexible pam architecture could prompt >> for type >> of authentication the user wants to try. > > There is nothing in the architecture or implementation of PAM that would > stop pam_krb5 from doing that. A module can prompt for anything it > likes it doesn't have to be restricted to just the standard PAM items.
I know that. But pam_authtok_get only prompts for user and password. I am arguing that if pam_authtok_get was enhanced to ask what type of authentication a users wants to try, it would be much more general, and all this special case use of pam_krb5 above or below pam_authtok_get would be much easier. I think I am arguing for what you are calling pam_eval below. > > For example pam_krb5 could prompt the user to choose PKINIT or Password > based auth when it starts. The prompting behaviour could be suppresesed > and a choice made based on a module option. Or pam_krb5 could even use > a new name=value pair in user_attr(4) that says wither PKINIT or > password should be used for a given user. Interesting says can work with LDAP too. The KDC might also be setup to only allow PKINIT and not a password for a user. > > A generic change though of allowing the user to pick which auth stack > they want to run (ie a set of modules configured by an admin) is a > different mater though. The work on pam_eval and per user stacks would > be helpful in that though. Yes, but it would have simplified this pam_krb5 changes. xscreensaver might still require pam_krb5 to do a prompt to give user a chance to insert the card... > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
