Re: contrib: auth_delay module

(2010/11/15 11:50), Robert Haas wrote:
> On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
>>> * Jan Urbański (wulczer(at)wulczer(dot)org) wrote:
>>>> On 04/11/10 14:09, Robert Haas wrote:
>>>>> Hmm, I wonder how useful this is given that restriction.
>>>>
>>>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
>>>> consuming), right?
>>>
>>> Which it would still do, since the attacker would be bumping up against
>>> max_connections. max_connections would be a DOS point, but that's no
>>> different from today. Other things could be put in place to address
>>> that (max # of connections from a given IP or range could be implemented
>>> using iptables, as an example).
>>>
>>> 5 second delay w/ max connections at 100 would mean max of 20 attempts
>>> per second, no? That's alot fewer than 100*(however many attempts can
>>> be done in a second). Doing a stupid while true; psql -d blah; done
>>> managed to get 50 successful ident auths+no-db-found errors done in a
>>> second on one box here. 5000>> 20, and I wasn't even trying.
>>
>> OK. I was just asking. I don't object to it if people think it's
>> useful, especially if they are looking at it as "I would actually use
>> this on my system" rather than "I can imagine a hypothetical person
>> using this".
>
> I haven't heard anyone say "yes, I would actually use this on my
> system"? Any takers?
>
My original motivation is to provide a proof of concept module for
the ClientAuthentication_hook, to show this hook is useful to other
purposes not only getpeercon() in SE-PgSQL.

If we don't need a PoC module for each new hooks, I'm not strongly
motivated to push it into contrib tree.
How about your opinion?

> If we're to commit this, then the patch needs to add a new file
> authdelay.smgl, fill it in with appropriate contents, and update
> contrib.sgml and filelist.sgml accordingly.

Sorry, I missed the manner of contrib modules.
It seems to me the dummy_seclabel module also lacks these documentation
updates, although its purpose is regression testing.

> I also note that the
> patch offers the ability to log superuser logins. Since that seems a
> bit off-topic for a contrib module called auth_delay, and since we
> already have a GUC called log_connections, I'm inclined to propose
> removing that part.
>
I agree with the suggestion.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>