On Tue, Apr 17, 2001 at 02:41:26PM -0500, Steve Langasek wrote: > On Tue, 17 Apr 2001 solar@openwall.com wrote: > > PAM isn't good for large virtual hosting setups. It's inefficient, > > doesn't have established virtual domain support, and common PAM modules > > aren't MT-safe. > > It's not clear to me that PAM lacks any features needed for virtual hosting. > If anything's missing, I imagine it's that we need a good pair of I agree that it might be just conventions that are missing, although it could be more consistent to define some extra PAM items. > (well-documented) modules which work well in conjunction to 1) provide a > mapping of the heirarchical, virtualhost namespace onto the flat local > namespace and 2) allow pulling information from multiple password databases > according to a 'domain' token. There are already modules that provide a > subset of 2, by bouncing all authentication for a service against a flatfile > or Berkeley DB file on the system, but I haven't seen anything yet that's > flexible enough to query multiple databases. In any case, I don't see having > anything as flexible as NSS without implementing 1 and actually stacking it > with a module that uses NSS itself. If a PAM module consults a database for authentication, then there should be a defined mechanism for it to extract and pass other information needed for the service or things become less efficient. > As for PAM modules that aren't thread-safe, can you point to specific cases? I think most aren't. The crypt(3) interface isn't thread-safe. glibc offers crypt_r(3), but no Linux-PAM module uses it. (I dislike how crypt_r(3) is implemented in glibc and the requirements it has, but that's another story.) I myself would avoid threads in network services as much as possible, but these issues are one of the reasons I can't just recommend PAM authentication in all cases. -- /sd
