On Tue, Apr 17, 2001 at 06:36:55PM -0500, Steve Langasek wrote:
> 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(). :)
Ok. I guess that means I should rip out all references to getpwnam() in
PAM_KRB5... Should be easy enough :)
> > > 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.
True. Send a bug report to {Sun, ISC, MIT}
> > 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?
Hmmm. You're right, the only way to automate such tests would be via a
source analyzer that looks for the use of non-thread-safe APIs, the use
of static or global variables, etc...
> Steve Langasek
> postmodern programmer
Nico
--
