> 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
