On 10/3/05, <b class="gmail_sendername">Alan DeKok</b> <<a href="mailto:aland@ox.org">aland@ox.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rich Graves <<a href="mailto:rcgraves@gmail.com">rcgraves@gmail.com</a>> wrote:<br>> This setup regularly fails under any sort of concurrency. Threading<br>> issues seem one likely reason. pam_radius_auth.c hasn't been touched
<br>> in a while an d hasn't had the same attention to thread safety as<br><br>  The PAM modules really aren't intended to be called more than once.<br><br>  The simplest solution is to put a mutex in the module.</blockquote>
<div><br>
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.<br>
<br>
[time passes]<br>
<br>
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.<br>
<br>
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.<br>
</div></div>