pam-list-request@xxxxxxxxxx wrote: > On Tue, Sep 25, Richter, Jörg wrote: > >> I wrote an application with my own conversation function to display and answer the pam requests with the help of a gui. >> >> I also included support for multiple pam_message's in one conversation call. This has the benefit to present the user only one dialog with two input field for user and password. >> >> But pam doesn't seem to use this functionality. It always calls the conversation function two times (resulting in two dialogs). >> > > Since there are two ways of how to handle multiple pam_messages in one > conversation call (Linux-PAM and Solaris are different/incompatbile here), > most PAM modules don't use this feature of the conversation interface. > > >> I know that every pam module can decide for itself what messages it wants to query from the application. But is there a way to force i.e. pam_unix to call the conversation function with user and password? >> > > There is no way to force a module of how it should query for > user and password. > > >> I can also imagine a pam module that queries user and password with one conversation call and stores it in pam_handle_t. Than tell pam_unix somehow to use this items instead of making new calls. >> Is this possible? Does this imaginary pam module exist? >> > > If you follow the recommendations in the pam module programmer's docs, even this is not clean, as it handles only the case, where you need exactly one user name and one (passive) password to be queried. A well written module doesn't call the conversation function itself, but simply issues a call to pam_get_item(), which in turn causes libpam to call the conversation function if necessary. There are modules, that don't need the credential (e.g. password) at all, but only the user name like pam_listfile or even neither name nor password like pam_securetty. Ihe pretty complicated case comes in when you try something like CHAP authentication. Here, first of all a user name is needed to produce a unique challange. This challenge is sent in place of a password-prompt to the querying instance. The instance itself queries the (real) user, builds an answer from the user name, the user password and the challenge and returns this to the authenticating pam module. As you see, in this case you depend on two-step conversation. Furthermore, if you take an approach as pointed out above, you are likely to produce an obscure dependency in the sequence of how the modules are called. Also, it is no longer possible to lock out those intruders silently, coming from a forbidden <rhost> or <tty>. What about a context sensitive graphical dialogue (try Glade!)? - Present a Username / Password window to the user, that contains an OK button (as in $indows) - set up an event, that triggers, when the user LEAVES the user name input field - Have the user fill in the user name - the trigger answers the conversation asking the user's name - keep the window open - wait for the password query - redraw the window, filling in the (now known) user name - place the cursor in the password input filed and have the user fill in the password - with the OK button pressed, close the window and send the pass word to the conversation function Andreas -- /Dr.-Ing. Andreas Schindler/ PDV-Systeme AZ1 GmbH Frankfurter Str. 141 63303 Dreieich Telefon 06103-57187-21 Telefax 06103-373245 schindler@xxxxxx www.az1.de PDV-Systeme AZ1 GmbH, Brandeniusstr. 3, 44265 Dortmund HRB 11089 Amtsgericht Dortmund, Geschäftsführer : Klaus-Jürgen Koke, Joachim Carle _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
