[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Thread-safeness of PAM / PAM-modules...



William M. Perry wrote:
> Are there any official 'thou shalt be thread-safe' guidelines for PAM
> module writers?

The official line on this is that provided you use a different pamh
for each thread, you are going to be safe.  I'm pretty confident that
the Linux libpam is thread safe in this way (although I have not
tested it ;).

The unfortunate fact is that there are a number of modules that use
static variables and this is likely to lead to some angst...  If you
run into them, they are true bugs and please bring them to my
attention!!  (Anyone want to volunteer to search for these?)

Note, Linux-PAM supplies the extra 'PAM_DATA_SILENT' flag that can be
OR'd with the second argument to pam_end().  This is intended to take
care of some problems endemic to a fork()d child doing a pam_end()
call.  It is intended to protect things external to the forked
process' image like temporary files from being deleted prematurely.
This idea could well be extended for threading if that is thought
appropriate.  To properly support this, we might need a pam_cleanup()
call added to the libpam API but Sun, in their wisdom, said they
really didn't like this...

When I use it, I tend to use the following application code:

    pam_start( ... &pamh );
    fork();
    if (child_process) {

	/* ... */

	pam_end(pamh, retcode
#ifdef PAM_DATA_SILENT
	| PAM_DATA_SILENT
#endif
	);
	pamh = NULL;
    }

    /* ... */
    pam_end(pamh, retcode);

Which is just to make me compile on a Sun too.

Cheers

Andrew
-- 
new job - new sig file under construction...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []