On 10/3/05, Alan DeKok <aland@ox.org> wrote:
Rich Graves <rcgraves@gmail.com> wrote:
This setup regularly fails under any sort of concurrency. Threading issues seem one likely reason. pam_radius_auth.c hasn't been touched in a while an d hasn't had the same attention to thread safety as
The PAM modules really aren't intended to be called more than once.
The simplest solution is to put a mutex in the module.
I know (just barely) enough to agree with that, but want more hints as to the granularity -- do I need to lock all of pam_sm_authenticate, or just talk_radius? Ideally, it would be nice to have a mutex per server and start the "all available servers" loop with pthread_mutex_trylock(), and keep track of which servers I haven't visited due to contention, but that gets hairy. [time passes] Ick. Well, with only a single conf->sockfd, there really is no choice but to put one big lock around the whole thing. If there was a different udp socket for each server in /etc/raddb/server, then I could have at least some parallellism, but that would require a lot of restructuring. Once I've done that work I might as well figure out how to make conf->sockfd private to each pthread. I was surprised not to find this issue in the archives, though I admit it is a little twisted to have a multithreaded LDAP server authenticate to Radius and not the other way around.