(2010/11/15 11:50), Robert Haas wrote:
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas<robertmh...@gmail.com> wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost<sfr...@snowman.net> wrote:
* Jan Urbański (wulc...@wulczer.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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
