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
