Rants inline... :) 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 > (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. IMHO, NSS needs to be revamped. As it stands it stinks. I'm not referring to any one implementation, but to the API. getpwnam() and friends are simply not good enough. Also, many PAM modules expect the PAM_USER to be a Unix user (they call getpwnam() on PAM_USER). This makes PAM unusable for the purpose of authenticating non-Unix users to Unix applications. Also, many PAM apps call getpwnam() on PAM_USER *before* calling pam_authenticate(). This model breaks the Windows 2000 / Active Directory model of needing valid user credentials to make such namespace lookups. You may not care now, but I think many users of Linux-PAM will, in time. I think a new NSS API is needed. One NOT limited by struct passwd; one that uses context structures like PAM or MIT/Heimdal krb5. And, one more thing: the Unix model of UIDs/GIDs sucks because UIDs/GIDs namespaces are FLAT. So username/groupname namespaces, in the Unix world, must also be FLAT. I believe a new syscall API for dealing with process credentials is needed. > As for PAM modules that aren't thread-safe, can you point to specific cases? PAM_KRB5. Because MIT krb5 is NOT thread safe. It's designed to be, but there are thread-safety issues in a number of places, including the ccache code, the rcache code, some of the OS-specific code (reentrant resolver calls are not used). I've seen this cause dtsession, on Solaris 2.6 with the latest dtsession patch crash. The crash was in initstate(), called by random() called by the resolver, called by MIT krb5. I'm working around this. > 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 don't have thread-safety tests, you won't know until you plug PAM into a thread app. > > 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. That would be nice. Yes. And password changing needs to be taken out of pam_unix and split into a module per-name service (e.g., pam_etc_passwd, pam_nis, pam_nis_plus, pam_bdb, pam_whatever...). > Steve Langasek > postmodern programmer Cheers, Nico --
