Rich Graves <[EMAIL PROTECTED]> 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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
