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

Re: pam_crypt module will change the world



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





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