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.)

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.

Steve Langasek wrote:
> I've found evidence that suggests there's a subtle but serious incompatibility
> between Linux-PAM's conversation function handling and that of other PAM
> implementations (apparently FreeBSD and Solaris). I'd appreciate it if anyone
> can confirm or deny this particular problem, and if it is a real problem I'd
> be interested to know what people think should be done about it.

Nothing. Perhaps file a bug report with the Solaris folk? ;)

> The second argument to the conversation function, 'const struct pam_message
> **msg', is unavoidably ambiguous; msg could be a pointer to (the address of
> the first element of) an array, or it could be (the address of the first
> element of) an array of pointers. It's clearly important to know which
> meaning is in use here, because incrementing the wrong pointer is a sure way
> to get a segfault. In Linux-PAM, the meaning is taken to be the second, 'an
> array of pointers', and this is how it's used by both the modules and the
> sample conversation function included in libpam_misc. And as long as everyone
> agrees on this usage, there's no problem.

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.

We can define conversations more flexibly using the Linux-PAM
definition, it thus it seems like the right one to me.

Cheers

Andrew

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

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