On Sun, Mar 04, 2001 at 01:45:59PM -0600, Steve Langasek wrote:
> 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 though FreeBSD was using Linux-PAM code, or code derive therefrom.
I bet the FreeBSD developers never fully tested/debugged this module in
question. After all, they did change the casts/prototypes in the
module's source to match the Linux-PAM prototype, but they didn't add
code to do the array of pointers to (struct pam_message), so they must
still have at least one or two compiler warnings and I imagine they
cannot do password changing or password aging without segfaulting.
[...]
> 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.
Prompt for one item at a time. That's the simplest workaround.
> > 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. :/
See above.
> > 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.
Hmmm. I think you're right, building an array of pointers is as
senseless in this case as it was for Sun developers to do conv(...,
&msg,...). Still, Linux-PAM does the right thing, given (struct
pam_message **).
> > Nothing. Perhaps file a bug report with the Solaris folk? ;)
>
> And FreeBSD, I guess. :) (Anyone know how HPUX handles this?)
Sigh.
> Steve Langasek
> postmodern programmer
>
Nico
--
