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 1r324s-001twT-Jw for pgsql-admin@arkaria.postgresql.org; Tue, 14 Nov 2023 22:40:14 +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 1r324q-00BOci-TV for pgsql-admin@arkaria.postgresql.org; Tue, 14 Nov 2023 22:40:12 +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 1r324q-00BOa7-HR for pgsql-admin@lists.postgresql.org; Tue, 14 Nov 2023 22:40:12 +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 1r324j-005bJa-Ih for pgsql-admin@lists.postgresql.org; Tue, 14 Nov 2023 22:40:11 +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 3AEMe2mo2537262; Tue, 14 Nov 2023 17:40:02 -0500 From: Tom Lane To: Andres Freund cc: Aditya D , pgsql-admin Subject: Re: pg_restore -L reordering of the statements does not work In-reply-to: <20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de> References: <1589825.1698431686@sss.pgh.pa.us> <20231114194933.ci3nxol3avtisyrs@awork3.anarazel.de> <2522830.1699994542@sss.pgh.pa.us> <20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 14 Nov 2023 14:27:43 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2537260.1700001602.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Nov 2023 17:40:02 -0500 Message-ID: <2537261.1700001602@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2023-11-14 15:42:22 -0500, Tom Lane wrote: >> Moreover, reordering the GRANTs is no solution, because who promised th= at >> the schema owner granted you any permissions? > I'm not quite following - the schema is created in the dump, so the gran= t is > part of it? Yeah, but the GRANT will restore whatever permissions existed in the source database. If the restoring user isn't super, those permissions don't necessarily grant him access. >> I experimented with making the restoring user be a member with inherit >> of the nosuper_N roles, and indeed I still see the failure above, >> which makes me wonder if the ACL check is being done correctly for >> that specific case. The INHERIT bit ought to let it work. > The check is for nosuper_2 to have permission on the schema ... no, it should be for the user executing the ALTER to have permission. > ... and the check > happens before the grant on the schema. For inherit to help, nosuper_2 w= ould > have to be granted membership to the presumably more privileged user doi= ng the > restore. No, surely the other way? Restoring user must be member of nosuper_2, else the ALTER OWNER won't work either. regards, tom lane