a suggestion for improving pkinit preauth plugin token choosing

Nicolas Williams Nicolas.Williams at oracle.com
Wed May 12 13:36:26 EDT 2010

On Wed, May 12, 2010 at 10:13:10AM -0700, Henry B. Hotz wrote:
> Why is everyone so afraid to let an attempt "fail"?  Maybe it's not
> your first choice, but why is it so bad?

An attempt to... login, I assume.

> If it "fails" then you can return a meaningful error message that
> tells the user how to do it over so it works.  You can say "I couldn't
> find any smart cards.", or "I found the following credentials and I
> don't know which one to use.  Please remove the extras and try
> again.", or "Please call extension HELP.", or even "Please call
> security to have yourself arrested because you are a dangerous
> terrorist."  ;-)

Not really.  The problem is that a PAM module might fail without the
whole stack failing.  If the module fails then presenting an error
message that's not relevant to the full login attempt would be
confusing.  But if the whole stack fails then... whence a useful

> You can tell the user absolutely anything you want that might be
> helpful, and you don't have any pre-existing constraints from a design
> that didn't anticipate your specific situation.

At that point you lack context as to what went wrong, so you have to
craft a long message telling the user everything they might need to

And even then: what decides what token to use and prompt for the PIN
for??  The [PAM] app?  That'd go against Solaris architecture.  But
you're saying the krb5 gic API shouldn't do it either.  How could some
other PAM module decide this in a way that works for all modules stacked
below?  And if pam_krb5 should do it by itself, then we'll be
duplicating much the same code in kinit and other gic applications.

Will and I have spent a lot of time looking at this.  This isn't a rash

Remember, complaining about PAM's shortcomings won't solve any problems
here.  Nor is this just about Solaris -- LinuxPAM has pretty much the
same set of problems as Solaris' PAM.


More information about the krbdev mailing list