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
