[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: User "accounting" module

Derrick J Brashear wrote:
> >  So, basically, you can have a huge hope that PAm won't interfere to much
> >  with RADIUS. But you'l; have to make sure that you don't use expensive
> >  time consuming modules for authentication. PAM as a thing doesn't take to
> >  much time, neither the load and unload of modules - linux buffer cache
> >  helps a lot - there are the time consuming modules that we'll make you
> >  belive that PAM is slow on a decent machine.
> >  
> Not that I think I could do it easily, but wouldn't the answer here seem to be
> a multithreaded radiusd?

Multi-threading pam applications raises an ugly spectre.. The PAM library
itself is designed with multi-threading in mind on the basis that
independent threads use independent pam_handle_t's (1 pamh per thread). To
the best of my knowledge this is fully realized in Linux-PAM's libpam.  It
is also the case for all (he hesitates before continuing;) the modules that
I have written, however, there are a number of modules that use 'static'
variables... The PAM documentation contains discussion of the
'pam_[gs]et_data()' functions which should make static variables within
modules unnecessary..

I just thought I might mention this, in case someone has time to scour the
code for 'static variables' and wants to make a contribution to the source.


               Linux-PAM, libpwdb, Orange-Linux and Linux-GSS

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []