Re: Lock Postgres account after X number of failed logins?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Lock Postgres account after X number of failed logins?
Дата
Msg-id 10842.1588705860@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Lock Postgres account after X number of failed logins?  ("Wolff, Ken L" <ken.l.wolff@lmco.com>)
Ответы Re: Lock Postgres account after X number of failed logins?
Список pgsql-general
"Wolff, Ken L" <ken.l.wolff@lmco.com> writes:
> I do understand what you described about locking down access through pg_hba.conf, so only authorized
users/applicationscan connect.  That makes a lot of sense and I’m going to take it forward to our Information Security
organization. However,  in case they won’t budge from this requirement, can someone tell me what would be the best way
tosubmit this as a feature request?  Simply edit the PostgreSQL Wiki ToDo page (https://wiki.postgresql.org/wiki/Todo)
oris there some other method. 

It's been discussed, but it's quite unlikely that we'd add features in
this area.  The project position is that if you have such requirements,
you can address them by using external authentication management, like
LDAP or PAM.  If we tried to take this on board, first we'd have a bunch
of problems with scope creep (because there are so many different random
requirements that people might have), and second we'd have a bunch of
architectural issues with where to keep the relevant state.  It can't
be ordinary database state --- at least not if you'd like to use the
feature on read-only slave servers, and even a single server would
have issues executing a transaction from a not-logged-in session ---
but then where *do* we keep it, and how would an admin see or adjust the
state?  It's a can of worms we don't really care to open, especially
when there are perfectly good solutions already available outside PG
proper.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Matthias Apitz
Дата:
Сообщение: Re: PostgreSQL client hangs sometimes on 'EXEC SQL PREPAREsid_sisisinst FROM :select_anw;'
Следующее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Thoughts on how to avoid a massive integer update.