Pam-list Digest, Vol 43, Issue 13

[Andreas Schindler]

pam-list-request at redhat.com 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 at az1.de
www.az1.de

PDV-Systeme AZ1 GmbH, Brandeniusstr. 3, 44265 Dortmund
HRB 11089 Amtsgericht Dortmund, Geschäftsführer : Klaus-Jürgen Koke,
Joachim Carle