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
