Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHWtp-008g3R-9y for pgsql-general@arkaria.postgresql.org; Wed, 12 Jun 2024 22:57:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sHWtl-009E9p-Um for pgsql-general@arkaria.postgresql.org; Wed, 12 Jun 2024 22:56:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHWtl-009E9h-KE for pgsql-general@lists.postgresql.org; Wed, 12 Jun 2024 22:56:58 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHWtj-0011oe-Tj for pgsql-general@lists.postgresql.org; Wed, 12 Jun 2024 22:56:57 +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 45CMus9t1691576; Wed, 12 Jun 2024 18:56:54 -0400 From: Tom Lane To: Ron Johnson cc: "pgsql-general@lists.postgresql.org" Subject: Re: PG16.1 security breach? In-reply-to: References: <8c533be4-5ed8-4658-86b6-212fb2d4d1a3@joeconway.com> <6d223a4891287cfb08b720103faef2da1b5719f3.camel@cybertec.at> <416045c0e7deac5b9f25e5fc89beec2a702a0b4c.camel@cybertec.at> Comments: In-reply-to Ron Johnson message dated "Wed, 12 Jun 2024 17:37:22 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1691574.1718233014.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 12 Jun 2024 18:56:54 -0400 Message-ID: <1691575.1718233014@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ron Johnson writes: > On Wed, Jun 12, 2024 at 4:36 PM David G. Johnston < > david.g.johnston@gmail.com> wrote: >> I think my point is that a paragraph like the following may be a useful >> addition: >> >> If one wishes to remove the default privilege granted to public to execute >> all newly created procedures it is necessary to revoke that privilege for >> every superuser in the system > That seems... excessive. More to the point, it's wrong. Superusers have every privilege there is "ex officio"; we don't even bother to look at the catalog entries when considering a privilege check for a superuser. Revoking their privileges will accomplish nothing, and it does nothing about the actual source of the problem (the default grant to PUBLIC) either. What I'd do if I didn't like this policy is some variant of ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Repeat for each schema that you think might be publicly readable (which is only public by default). BTW, in PG 15 and up, the public schema is not writable by default, which attacks basically the same problem from a different direction. regards, tom lane