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

Re: pam_crypt module will change the world

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

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