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.