> Ondrej Svetlik wrote:
> > int myConv(int numMsg, const struct pam_message **msg,
> > struct pam_response **response, void *appdataPtr)
> [snip]
> > *resp = reply;
>
> I'm assuming that was supposed to be:
>
> *response = reply;

Of course (-:. I wrote this example directly into the email, it was never
tested.

>
> to match the function header since resp isn't declared anywhere. I've
> also just realized the unusual way *appdataPtr is used to pass data in
> from the app.
>
> I would also assume that you could stick the code to obtain the username
> and password directly in the conversation function's code- but it's
> probably a good idea not to.

Of course, you can. It's up to you. It's quite usual to ask user to type
password in conversation function. This example was inspired by an
authentication function which took a password as an argument, so there was
no need to as user for it. I also use application data to store actual
state. For example when changing password, the conv function is called
three times with echo off, and is supposed to return the old password once
and then twice the new one.

>
> > case PAM_PROMPT_ECHO_OFF: /* ? password */
> > case PAM_PROMPT_ECHO_ON: /* ? username */
>
> How reliable are these correlations? (echo-off for username, echo-on
> for password)

I'm not sure, it just works for me (-:.

>
> Many thanks for the example; it's starting to make a little more sense
> now.

You're welcome.

-oxs

_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]