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
