[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