Steve,
Yes, I see. Solaris conversation functions expect a pointer to the first
of a set of contiguous (struct pam_message). Linux-PAM's misc_conv()
expects a pointer to an array of pointers to (struct pam_message).
What a horrid mistake Sun's developers made. Eeck.
We can probably put in #ifdef'ed fixes for this in all modules that
prompt for more than one item at a time.
Another possible fix would be to make a module prompt for one item at a
time. That was something I was already going to make an option in this
module because CDE's dtgreet only handles a prompt at a time anyways
(which means dtlogin has to break-up multi-prompts and, I think, it is
buggy wrt multi-prompts, at least on Solaris 8 BETA_REFRESH [yes, I
need to upgrade]).
I see no reason why it is necessary or better to send these three prompts at
once rather than one after the other:
"Password expired. You must change it now."
"Enter new password"
"Enter it again"
That would be a simple fix, though it will only work as long as there
isn't an absolute need to prompt multiple prompts in one go.
Nico
On Sat, Mar 03, 2001 at 05:12:19PM -0600, Steve Langasek wrote:
> Hello all,
>
> 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.
>
> Background
>
> The type of the conversation function is defined in the PAM header files as
> follows:
>
> struct pam_conv {
> int (*conv)(int num_msg, const struct pam_message **msg,
> struct pam_response **resp, void *appdata_ptr);
> void *appdata_ptr;
> };
>
> 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.
>
>
> Problem
>
> I recently downloaded and compiled Frank Cusack's pam_krb5 module. You can
> imagine my dismay when I found that my application was segfaulting for
> precisely the reason mentioned above: instead of passing an array of pointers
> to my conversation function, pam_krb5 was passing a pointer to an array. This
> is clearly not just a bug in pam_krb5, because it leaves the password-changing
> functionality entirely broken under Linux-PAM and my entire motive for
> downloading the module was that Nicolas Williams asserted that it handled
> password expiry correctly. Checking with him, I've confirmed that none of the
> patches he's applied to the source change the usage of the conversation
> function. So the only explanation I have is that this module works... just
> not with Linux-PAM.
>
>
> Solution?
>
> If it's true that we have an API incompatibility here, the question then
> becomes, what do we do about it? That the problem should escape notice for so
> long is a sure indication that few people are affected by it, probably because
> few PAM modules ever call the conversation function with more than one message
> at a time. As developers' use of PAM becomes more complex, however, and as we
> move towards the goal of 'OpenPAM', this incompatibility will become more of a
> problem for those trying to write cross-platform PAM modules and conversation
> functions.
>
> The good news is that the problem affects only the conversation functions and
> the modules; a change in behavior won't require a recompile of many
> applications (none of those that use libpam_misc's misc_conv). The bad news
> is, changing Linux-PAM will make it incompatible with existing third-party
> modules and with applications that provide their own conversation functions.
> This would make the switch painful in the short term, but IMHO the long-term
> benefits make this the right decision... the longer the situation is allowed
> to persist, the more painful it would be to correct the problem in the future.
>
> Steve Langasek
> postmodern programmer
>
>
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
--
