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

Re: PAM threadsafe?



Hello Devin,

On Mon, 9 Jul 2001, Devin Heitmueller wrote:

> I am working on a multithreaded server that makes use of PAM to
> authenticate connecting users.

> It would appear that pam_pwdb uses static variables for its bigcrypt
> and md5 routines.  This caused problems when multiple threads
> attempted to run these functions.  It would appear that these
> functions (at a minimum) are not reentrant.

> Has anyone attempted to use PAM in a multithreaded environment?  Are
> there any opinions on how feasible this is?  I am wondering if the
> one issue I've spotted thus far is just the tip of the iceberg.

By and large, PAM tries to be thread-safe, but there are various places where
it falls short of that goal.  Both pam_pwdb and pam_unix are known to have
problems (mostly the same problems, since they shared much of the same code
base in an earlier day).

The lack of a thread-safe pam_unix-like module is the biggest stumbling block
for multithreaded PAM apps right now; most other reentrancy issues are likely
to be in seldom-used modules that aren't needed for getting PAM on its feet.

Patches to fix any thread-safe issues in PAM or its modules would be
enthusiastically accepted.  I'm currently looking at the pam_unix code to at
least resolve some of the more superficial problems.  In addition to the
static variables employed in pam_unix, there's also a question of
non-reentrant libc functions being used.

Looking at the bigcrypt and md5 routines, I see no reason that static
variables should even be used -- I'll fix this in CVS ASAP.  I imagine that
some of the other, more complex reentrancy issues are going to cause you
problems as well, though.

HTH,
Steve Langasek
postmodern programmer





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