Steve Langasek wrote:
> I agree. It seems it was only ever specified as 'struct pam_message **' by
> failed analogy with 'char ** argv'. But now we're stuck with the
> double-pointer, and have to make some sense out of it. :/
>
> > We can define conversations more flexibly using the Linux-PAM
> > definition, thus it seems like the right one to me.
>
> I don't follow you here. How does the Linux-PAM definition give us more
> flexibility? All I see is added complexity. If the double-pointer is
Its been my experience that an extra layer of abstraction generally
means more flexibility.
If I'm a module writer, I'm not allowed to use writable static data
since I have to watch out for the application calling pam_start()
multiple times. But I can use static read-only data.
I might need to do a conversation like this: {PAM_TEXT:"You need to
re-enter your password"} {PAM_NOECHO, "password for luser: "}. With the
Linux-PAM convention, I can build the message structure for the first
prompt at compile time, and simply malloc a pointer array at run time.
With the Solaris definition, I need to malloc the whole pam_message
array structure in one go and copy in each prompt.
If I have a variable number of prompts depending on context and I want
to construct the conversation out of a fixed set of prompts, then I can
mix and match with fewer memory copies than if I have to memcpy message
arrays at run time.
Neither of these reasons are compelling, I realize, but they are
features of the current conventions that folk may be using.
> unnecessary to begin with, then it seems to me we should limit as much as
> possible its impact on the module writer's code. To make pam_krb5 work with
> Linux-PAM, I had to insert
>
> for (i = 0; i < pam_prompts; i++) {
> pmsg[i] = &msg[i];
> }
>
> into the code, whereas with the Solaris interpretation,
>
> pmsg = &msg;
>
> would be sufficient. I think the first method obfuscates more than it does
This makes very little sense to me as an argument. Are you saying that
this one module is some sort of definition of correct behavior?
> anything else. Really, it doesn't matter too much to me; I'll just go along
> with whatever the general consensus is. I'm just eager that a consensus be
> reached, so that this doesn't become a long-term headache.
Its already a headache. I just see no way to cure it with a change to
the Linux-PAM distribution without breaking backward compatibility with
untold modules out there.
> > Nothing. Perhaps file a bug report with the Solaris folk? ;)
>
> And FreeBSD, I guess. :) (Anyone know how HPUX handles this?)
How the FreeBSD folk messed this up I have no idea. They used the Linux
codebase, and besides inheriting sample source code, they had explicit
directions in the inherited documentation for this issue. I think you
will find that to this day Sun has not documented its preferred behavior
anywhere.
Here is the man page entry on Solaris for the conversation function, it
is clearly not consistent with itself:
===
int conv(int num_msg,
const struct pam_message **msg,
struct pam_response **resp,
void *appdata_ptr);
[...]
The parameter num_msg is the number of messages associated
with the call. The parameter msg is a pointer to an array
of length num_msg of the pam_message structure.
===
Cheers
Andrew
