[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 2nd call: binary incompatibility (another monkey wrench?)

Another point of confusion I have found with the docs (from the Solaris side)
is what **'s really mean in the conversation function.  When I started with
pam under 2.6 I assumed they were an array of pointers.  What I have found in
practice is that they are pointers to an array.  I haven't looked at the
source for the Linux implementation (probably should), but the krb5/pam
implementation seems to assume they are an array of pointers as I had
originally assumed.  The following snipit seems to work under Solaris 2.6:


    struct pam_message msgs[3], *msg;
    struct pam_response *resp;
    i = 0;

    if(!user) {
        prompt = NULL;
        pam_get_item(pamh, PAM_USER_PROMPT, (void **) &prompt);
             prompt = "login:";
        msgs[i].msg_style = PAM_PROMPT_ECHO_ON;
        msgs[i].msg = prompt;
    msgs[i].msg_style = PAM_PROMPT_ECHO_OFF;
    msgs[i].msg = "SecurID Passcode: ";
    msg = msgs;

    stat = (*conv->conv)(i, &msg, &resp, conv->appdata_ptr);


I only ran into problem when I tried to pass more than one message or get
more than one response.  Responses seem to work the same way as messages.

					Fred Romelfanger
					Sr. Systems Engineer
					Space Telescope Science Institute

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []