[tac_plus] Re: tac_plus AFL (Auth Fail Lock)

Mark Ellzey Thomas mark.thomas at corp.aol.com
Fri Jun 27 18:00:28 UTC 2008


On Fri, Jun 27, 2008 at 10:11:59AM -0700, john heasley wrote:
> Mon, Jun 23, 2008 at 03:11:54PM -0400, Mark Ellzey Thomas:
> > Greetings all,
> > 
> > Recently we have had the need for tac_plus to temporarily disable user
> > accounts based on the number of authentication failures the user has had
> > in a defined window of time.
> > 
> > Attached is a patch against F4.0.4.15 with the previously submitted
> > acct+syslog patch (if this is a problem please inform me and I will
> > patch against the base F4.0.4.15 tree). 
> > 
> > The following global configuration parameter has been added:
> > 
> > auth-fail-lock $int1 $int2 $int3
> > 
> > Where $int1 is the number of authentication failures
> > Where $int2 is the window (in seconds) in which to watch for auth fails
> > Where $int3 is the number of seconds to disable the user. 
> > 
> 
> Does this (cursory glance) purposely not clear the blocked accounts on
> HUP?
> 

HUP is handled by handler() who calls init() which calls
cfg_create_failure_shm(). This function will reinitialize all
of the users:

while(entry)
{
...
	bzero(failed_node, sizeof(struct failed_node));
...

This should in essence wipe the failed_node->disabled flag.

> 	...
> 
> I wonder if its just time to thread tac_plusd.

I actually started down a different path of using libevent
(http://monkey.org/~provos/libevent/) which is a portable library
that uses the best possible mechanism for your OS to signal fd
readiness.  

In my own personal experience I have found that you can achieve greater
performance and very maintainable code (e.g., avoiding mutex nightmares)
by doing something like this.

I should have the initial patches complete within the next 2 weeks or
so. I not asking them to be accepted, but to be viewed as a potential
new architecture.


More information about the tac_plus mailing list