Joachim Keltsch <[EMAIL PROTECTED]> writes:
> Package: libpam-krb5
> Version: 2.2-1
> Severity: serious
> Hello *,
> The pam_krb5.so module provides a callback function that queries users
> for their passwords or displays informational messages. This callback is
> registered to various Kerberos functions. All of these Kerberos
> functions usually call the callback with ONE message string only.
> This works perfectly fine.
> However, if a user is to change her password, Kerberos will call the
> callback with THREE messages:
> i) Password expired. You must change it now.
> ii) Enter new password:
> iii) Enter it again:
> The array of pointers to these messages is handled incorrectly.
> It is processed as:
> one single pointer pointing to an array of pam_messages.
> However, PAM expects it to be:
> an array of pointers, each pointing to one single pam_message
Yeah, this would be the following problem, noted in the PAM application
developer's guide:
In passing, it is worth noting that there is a descrepency between the
way Linux-PAM handles the const struct pam_message **msg conversation
function argument from the way that Solaris' PAM (and derivitives,
known to include HP/UX, are there others?) does. Linux-PAM interprets
the msg argument as entirely equivalent to the following prototype
const struct pam_message *msg[] (which, in spirit, is consistent with
the commonly used prototypes for argv argument to the familiar main()
function: char **argv; and char *argv[]). Said another way Linux-PAM
interprets the msg argument as a pointer to an array of num_meg read
only 'struct pam_message' pointers. Solaris' PAM implementation
interprets this argument as a pointer to a pointer to an array of
num_meg pam_message structures. Fortunately, perhaps, for most
module/application developers when num_msg has a value of one these
two definitions are entirely equivalent. Unfortunately, casually
raising this number to two has led to unanticipated compatibility
problems.
I believe the conversation function may have originally been written for
Solaris.
It looks like your patch implements the workaround described there. Thank
you! It will be in the next release, which I'll try to upload in the next
few days.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
