On Sat, 3 Mar 2001, Andrew Morgan wrote:
> Yes, this is a known problem. (I recently [months ago] submitted a patch
> to openssh to cover this issue - someone 'fixed' the original PAM code
> to stop working like the Linux library and start working like the
> Solaris one - I explained the difference then, and Damien added some
> conditional compilation to cover it.)
Interesting. So does OpenBSD itself use the Linux-PAM interpretation (if they
even use PAM in the distro)? It appears that FreeBSD follows Solaris'
interpretation.
> I firmly believe this is a Solaris implementation bug.
> I think the Sun guys didn't think when they implemented this. I actually
> asked the Sun guys about it when I was writing this part of libpam_misc
> (5 years ago?) and they never gave any response. The first I heard that
> they had implemented it wrongly was actually about a year ago, when a
> commercial module developer emailed me to say that they'd run into this
> problem with their module and had opted to support both meanings of
> 'pam_message **' in what they passed to the conversation function.
> Slightly sick, but quite doable.
Yes, I think the sickening aspect of this approach is a concern. :) I also
think it's an unnecessary barrier to writing cross-platform PAM modules and
aapplications, a barrier that will have a negative effect.
> Consider the similarity with the common practice definition:
> main(int argc, char **argv)
> {
> /* .. */
> }
> If we look at what Sun implements, its this:
> conv(...., x, ....);
> where x = &y; y = &m[0]; and m[0]....m[n] is there message array. By
> what logic can one possibly justify the indirection introduced by using
> 'y'?
> If the prototype had been this:
> int (*conv)(int num_msg, const struct pam_message *msg,
> struct pam_response **resp, void *appdata_ptr);
> this issue would not have arisen.
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
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
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.
> Nothing. Perhaps file a bug report with the Solaris folk? ;)
And FreeBSD, I guess. :) (Anyone know how HPUX handles this?)
Steve Langasek
postmodern programmer
