> While working out the various permutations of PAM auth stacks I've
> discovered that my fasttrack was not complete in regards to new
> interfaces.
At yesterday's meeting, I asked for more time through today.
Unfortuntely, I'm not going to be able to get through this
case today. So, I'd like to ask the case be extended to next
meeting.
A few brief comments that may have already been covered,
if so, I apologize. 1st, I think pam_eval() that Nico mentioned
could well be a positive alternative -- I know I'm the bottle
neck in code review. 2nd, applications can set PAM_AUTHTOK
just the same way they can set PAM_USER. So keying off unset
PAM_USER/PAM_AUTHTOK may not be as robust as it might have been
thought. 3rd, a module could be written and stacked above
pam_authtok_get(5) that prompted for what type of authentication
was desired and set PAM_PROMPT before returning PAM_IGNORE
and falling into pam_authtok_get(5).
I'm working to get caught up on this case.
I unfortunately missed the pre-review and when I asked where it
stood, was told the issues had been resolved.
More later,
Gary..
P.S. I, too, would really like to see a man page update for pam_krb5(5)
as a separate part of the case materials.
