Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nf5Et-0006N7-V9 for pgsql-admin@arkaria.postgresql.org; Thu, 14 Apr 2022 19:34:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nf5Es-0001br-99 for pgsql-admin@arkaria.postgresql.org; Thu, 14 Apr 2022 19:34:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nf5Er-0001bi-Uc for pgsql-admin@lists.postgresql.org; Thu, 14 Apr 2022 19:34:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nf5Ep-0005s4-Lr for pgsql-admin@lists.postgresql.org; Thu, 14 Apr 2022 19:34:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23EJYgIw1537965; Thu, 14 Apr 2022 15:34:42 -0400 From: Tom Lane To: "David G. Johnston" cc: Sbob , Pgsql-admin Subject: Re: query to show locked / disabled users? In-reply-to: References: Comments: In-reply-to "David G. Johnston" message dated "Thu, 14 Apr 2022 12:24:17 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1537963.1649964882.1@sss.pgh.pa.us> Date: Thu, 14 Apr 2022 15:34:42 -0400 Message-ID: <1537964.1649964882@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Thursday, April 14, 2022, Sbob wrote: >> I have a client that says there were break in attempts and many db users >> are now disabled / locked because of too many wrong pw attempts. Is there >> a select that will show these users? > You can look at pg_roles. That probably won't help much, because Postgres has no built-in mechanism for disabling users on the basis of "too many wrong pw attempts". Whatever has decided that must be external to Postgres (perhaps getting accessed via LDAP or PAM?) and you're going to have to look at its state. In short, there's not enough info here for us to offer any useful advice. regards, tom lane