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 (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. As for PAM modules that aren't thread-safe, can you point to specific cases? I know that Andrew stresses thread-safe programming in PAM modules, but I imagine there's some crufty code in the Linux-PAM tree by now that even Andrew hasn't looked at in years. If there are issues with modules not being thread-safe, I'd like to address them before I have an opportunity to run into them in the field. > If you implement a framework for password hashing modules, it should > be separate from PAM. If someone creates an API for password hashing modules, there's no reason it should be tied to PAM. It would be nice if PAM modules could make use of it, of course. Steve Langasek postmodern programmer
