Answers to the Issues of Fingerprint authentication (PSARC 2007/286)

[Jörg Barfurth]

Darren J Moffat schrieb:

> I think this project should NOT be introducing multi-threaded PAM 
> module, or expecting PAM applications to be multi-threaded 

Don't the message types below do just that? Using PAM_CONV_INTERRUPT 
(and thus PAM_MSG_NOCONF) requires that the module using them is 
multi-threaded and that the PAM application supports reentering its 
conversation function in another thread.

> nor should it 
> be trying to do things with the X input model.  I believe that this case 
> should following the existing architecture that is used for smartcard 
> support via PAM and the login applications.  

IMHO that architecture seems woefully incomplete - or at least unclear.

Reviewing the meaning and intended use of PAM_MSG_NOCONF and 
PAM_CONV_INTERRUPT in PSARC/1999/223 it is not at all clear to me how to 
replace them for PAM clients that don't support these messages.

PAM_MSG_NOCONF has relatively clear control flow implications. 
Apparently it is intended to mean:
- show message indefinitely (at least as long as conv() is running)
- don't return from conv() until PAM_CONV_INTERRUPT is received
- don't provide a control to (successfully) return from conv()

But the meaning of PAM_TEXT_INFO or PAM_ERROR_MSG for control flow is 
far less clear. Some possible flows (that are seen in the wild) are:

(1) Textbased clients, but also some GUIs (dtlogin "modern style", gdm)
- Print the message modelessly
- Leave it visible after conv() returns until it scrolls out of sight or 
the greeter is closed.
- return from conv() at once.
- A variation of this is:
   (1a) Leave message visible only until next conv() call.

(2) Some GUIs (e.g. classical dtlogin)
- Show the message modally with a control to acknowledge
- Erase the message (close the window) when acknowledged
- Don't return from conv() until message has been acknowledged
- This model implicitly applies when a PAM_TEXT_INFO message is grouped 
with a PAM_PROMPT_* message, because those always require explicit user 
confirmation.

As a result PAM_TEXT_INFO cannot reliably be used to request fingerprint 
or card insertion, because it isn't clear whether the message is shown 
synchronously or not. In the former case, the reader would have to be 
driven asynchronously and return from conv() before a successful read 
has happened should loop to retry. But when the message is shown 
asynchronously, reading should happen synchronously after conv() has 
returned.

Note that dtlogin modern style even has a bug that may cause such 
messages to never be seen - the message is dumped to the greeter, but 
that greeter is shown only if and when/after a PAM_PROMPT_* conversation 
happens. So in such a case there is not even a guarantee that the 
message has been seen by the user at all when conv() returns.

So the final resort would be to use a PAM_PROMPT_ECHO_<whatever> 
conversation to force conv() to show synchronous behavior. As no input 
is really required and any response typed by the user discarded, this 
would be an awful hack and nothing I'd consider architecture.

> That likely means that the 
> currently private (and marked obsolete) message types below should be 
> formalised and made Committed - assuming the solve the same problem for 
> fingerprint readers that they do for smartcard.
> 
> #define PAM_MSG_NOCONF          2001    /* No confirmation from user */
> #define PAM_CONV_INTERRUPT      2002    /* Return from conv() */
> 

I'm wondering if they really (still) solve it for smartcards (and for at 
least most of the PAM clients in Solaris today).

- Jörg

-- 
Joerg Barfurth           Phone: +49 40 23646662
Software Engineer        mailto:joerg.barfurth at sun.com
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering