[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, Nicolas Williams wrote:

> 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.

I would certainly call this a bug (except in modules like, say, pam_unix).
Not something that we can't fix without replacing getpwnam(). :)

> > 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).

Not the fault of the PAM module, then.  If you don't have thread-safe Kerberos
libraries, it doesn't matter whether we use PAM; we'd have the same problem if
we wrote directly to the Kerberos APIs.  Still should be fixed, of course.


> > 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.

I thought it was fairly straightforward to determine if a given piece of code
is thread-safe.  Are you suggesting that there are better (automated) ways
to check thread-safety than manual inspection?

Steve Langasek
postmodern programmer





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