Re: contrib: auth_delay module
От | KaiGai Kohei |
---|---|
Тема | Re: contrib: auth_delay module |
Дата | |
Msg-id | 4CE32CCC.1040209@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: contrib: auth_delay module (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: contrib: auth_delay module
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
(2010/11/15 11:50), Robert Haas wrote: > On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas<robertmhaas@gmail.com> wrote: >> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost<sfrost@snowman.net> wrote: >>> * Jan Urbański (wulczer@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 <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления:
Следующее
От: Itagaki TakahiroДата:
Сообщение: Re: Extensible executor nodes for preparation of SQL/MED