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

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

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