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

Re: pam_crypt module will change the world

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?


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



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