On Fri, 1 Sep 2000, Nikolay Pelov wrote:
> PAM already supports setting two user-defined callback functions:
> conversation function and fail-delay function. And there is a
> standard convention how to set and retreive them:
>
> pam_(set|get)_item(pamh, PAM_CONV, conv_func);
> pam_(set|get)_item(pamh, PAM_FAIL_DELAY, fail_delay_func);
>
> So, I think we should stick with this principle and use
>
> pam_set_item(pamh, PAM_LOG_CALLBACK, newcb);
> pam_get_item(pamh, PAM_LOG_CALLBACK, &newcb);
>
> instead of introducting new function which does exatcly the same like:
>
> > pam_log_callback_t *pam_set_log_callback(pam_handle_t *pamh,
> > pam_log_callback_t *newcb);
Nice idea. BUT...
One of the main efforts underway at present is to ensure that "Linux-PAM"
is portable to other operating systems, not just Linux. (Example: be able
to take a Linux-PAM module and put it into a Solaris system.) And I
understand that Andrew Morgan is keen that (so called) "Linux-PAM" be
made, and kept, portable and ultimately regarded, if possible, as
"Open-PAM".
Are we sure that every current and future PAM implementation from every
commercial OS vendor will accept use of arbitrary new "item types", such
as the proposed "PAM_LOG_CALLBACK"? Is it not quite probable that some
PAM framework on some vendor's OS will internally implement
"pam_(set|get)_item()" as:
pam_(set|get)_item(..., int item_type, ...)
{
switch (item_type) {
case PAM_AUTHTOK: /* known to this vendor */
[... ]
break;
[... similarly for other known item_type ...]
default: /* unknown to this vendor */
[... complain bitterly and fail ...]
}
}
So just a note of caution, not to paint ourselves further into a
"Linux-only" corner, when this product deserves wider use.
--
: David Lee I.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/~dcl0tdl South Road :
: Durham :
: Phone: +44 191 374 2882 U.K. :
