pam_radius_auth threading issues
I've inherited a setup with authentication information on a local freeradius 1.0.5 server and OpenLDAP (with pthreads) configured to authenticate to SASL (v1 interface), which in turn uses PAM, which in turn is configured to check passwords with pam_radius_auth 1.3.16. All of this is on Linux RHEL3. 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 and hasn't had the same attention to thread safety as the core freeradius code. Has anyone else been down the road of cleaning up the calls to gethostbyname, variable scoping, etc? I know enough to recognize the problem, but don't really trust myself to fix it. Obvious workarounds for me include switching from SASL1/PAM to SASL2 and saslauthd; de-threading OpenLDAP (ick); or migrating the authoritative password store out of Radius entirely. But all of these have performance or operational issues here. I'd really like to get pam_radius_auth working as my predecessors (wrongly) thought it would.
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 core freeradius code.
The PAM modules really aren't intended to be called more than once. The simplest solution is to put a mutex in the module. Alan DeKok.
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.
Rich Graves <rcgraves@gmail.com> wrote:
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?
I would lock each PAM function.
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.
If we can get the radius library code from FreeRADIUS into shape, we can fix those issues in the pam module by using library code. Alan DeKOk.
participants (2)
-
Alan DeKok -
Rich Graves