Re: Lock Postgres account after X number of failed logins? - Mailing list pgsql-general

From Tom Lane
Subject Re: Lock Postgres account after X number of failed logins?
Date
Msg-id 10842.1588705860@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lock Postgres account after X number of failed logins?  ("Wolff, Ken L" <ken.l.wolff@lmco.com>)
Responses Re: Lock Postgres account after X number of failed logins?  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Matthias Apitz
Date:
Subject: Re: PostgreSQL client hangs sometimes on 'EXEC SQL PREPAREsid_sisisinst FROM :select_anw;'
Next
From: "Peter J. Holzer"
Date:
Subject: Re: Thoughts on how to avoid a massive integer update.