pam_radius_auth threading issues

[Rich Graves]

On 10/3/05, Alan DeKok <aland at ox.org> wrote:
>
> Rich Graves <rcgraves at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20051004/f763959d/attachment.html>