Hello,
After having developped an application on HPUX we decided to port it on Linux
(Linux Version: 2.4.21-27.0.4.EL build with gcc 3.2.3, Read-Hat version
3.2.3-52).
In order to use our application the user has to authenticate himself. We based
the Authentication mechanism on the old Unix style username/password. PAM
"exists" on HPUX word but I would say it's not really popular (yet) and really
limited compared to the Linux word (MISC, RADIUS, LDAP, and so on PAM modules).
Nevertheless, since PAM has to be used on Linux (customer's requirement) we
started investigating how to replace our
username/password mechanism by PAM (for each platorm, since we don't really
want to support two mechanisms).
We found a lot of information on PAM which helped us understand how PAM works.
Nevertheless, we still have a few questions
(mainly about the "Conversation function") and we would really appreciate your
help here.
First on Linux we wanted to use the misc_conv conversation function which seems
to have been designed for that:
"This is a function that will prompt the user with the appropriate comments and
obtain the appropriate inputs as directed by authentication modules"
Unfortunatly we got a compilation error:
/usr/include.security/pam_client.h:55 non-local
function 'int pamc_converce(pamc_handle_s*, <anonymous struct>**)'uses
anonymous type.
Both with C or C++ compiler (gcc version 3.2.3).
Has anyone had the same problem?
Nevertheless, reading the code (misc_conv.c plus other resources) we finally
wrote our own conversation method, mainly based on the misc_conv.c. Basically,
on PAM_PROMPT_ECHO_OF we are expecting a password (using "getpass()"like
code) and on PAM_PROMPT_ECHO_ON we are excepting a user input (I can provide
the code if this is of any help).
This works pretty well: both on Linux and on HPUX the username/password check
is done via PAM.
If we understand how Application/PAM/"Security back-end" (NIS, LDAP, ...) work,
it's not clear how the Conversation function works.
Is it standard to enter a password when the msg_type is PAM_PROMPT_ECHO_OFF?
Is it standard to enter a text/username when the msg_type is
PAM_PROMPT_ECHO_ON?
Moreover, in case we decide to use a Radius server for the "checking", will our
code still work?
So far we have written something like:
switch (msgm[count]->msg_style) {
case PAM_PROMPT_ECHO_OFF:
string =
read_string(CONV_ECHO_OFF,msgm[count]->msg);
if (string == NULL) {
goto failed_conversation;
}
...
Where read_string() "reads a line of input giving prompt when appropriate" (yes
similar to the read_string() method provided by pam_misc.so ...).
The application is Radius unaware (we understand that the application with PAM
doesn't have to care which security module does the job at the end). The
question is : Does the misc_conv function still work if we decide to use the
pam_radius_auth library instead of the pam_stack or pam_unix library inside the
PAM configuration file?
We had a look at Applications using LDAP PAM module and we saw that in this
case the application has the knowledge of the LDAP server (to retrieve the user
and the password for instance and pass that information to the Conversation
method)
Of course using the LDAP server inside the application to retrieve both the
username and password doesn't necessarily means that the PAM module will also
use the LDAP server for the checking. On the other hand, if on the
configuration file we replace pam_ldap.so by pam_stack.so, there is a great
chance that nobody can log to the application anymore (since the
NIS username/password are probably different from the Directory
username/password).
The remark also applies to Radius and probably other technologies (for radius
the application has to contact the server to get a list of usernames for
instance).
The point here is: Is the Conversation function really "techno unaware" or not?
Otherwise this also means that the administrator is not really free to change
the PAM configuration file (the risk is that the application cannot
provide the right information to the PAM module and the authentication will
fail).
Of course since it is possible to provide several "backups" inside the
configuration file, the problem is not critical but we would like to have your
feedback on that.
Thanks for your help,
Pierre.
_______________________________________________
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
