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 1nuoQH-0008Me-9m for pgsql-bugs@arkaria.postgresql.org; Sat, 28 May 2022 04:51:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nuoQE-0002Wc-Rw for pgsql-bugs@arkaria.postgresql.org; Sat, 28 May 2022 04:51:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nuoQE-0002WS-KG for pgsql-bugs@lists.postgresql.org; Sat, 28 May 2022 04:51:30 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nuoQB-0002r4-9d for pgsql-bugs@lists.postgresql.org; Sat, 28 May 2022 04:51:29 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-d39f741ba0so7992931fac.13 for ; Fri, 27 May 2022 21:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rKkTnGciwmCaI14ePEyvZ4NmXQx5KRA5sOiijU+vhtg=; b=NFNc6l9MjPVyenfIsCNcmtgGmL+ipnIGUHAdUO8JPO6LOQNTnyCa/DSwxrcJdLa/Or ISgsKvdf2glsfHxl+9BDdHM/92Hs0zhOM27WhnToaV2oq+URTqYQCT1NMQDBpzkcSVgY drjwXl9i5Ks6b7Y+MoBmaM1ad01TXTnl4fxQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rKkTnGciwmCaI14ePEyvZ4NmXQx5KRA5sOiijU+vhtg=; b=1/dp3Cfqz81or4LH4TpWw/rNmGCAOqGaCRXmnMThQKtjtZzrEucDSziHIBHgvxeAsa 42Ufj838DmLiqIlPi/dgo6jzLW6V8PP2NKEQ3vKvTq2NPVUKJ4Lt5H90QQEBXN+gnbjS Uf2d6NbaanwvvpHlIq12reVxYdTEL04zYulcqAeHS8WRztzWjJ+K2wqiH+YAbpDdmkNQ INZxN4CTJ7DR0vCXwxobN158ZmI2HYxAN+wqCkmLP/yPjmLImDrDaLQcrNLyKJjrEeni McI9f0T8hOUXlS/Sx7QzMEE63Ho+/cbhUcyOLPxMOASzA0lVLHaOetrVHX4DFFSeUbYS 4EFA== X-Gm-Message-State: AOAM531qe0fwsU308nIUDHeqX+fdnIBATJyTYPNM+kG/PYW0d+KWQ9sf LUAVKf0bRBNPFVXJ2rG/aEEq1HmQurQD/w== X-Google-Smtp-Source: ABdhPJzJOkcbzbheH88Xs7U8EMkIRccPa3stL8lhorUWc1zQCSYi+RRLVe02Av5zyVogEJsX1gv7Rw== X-Received: by 2002:a05:6870:b4a4:b0:f2:5b63:5b91 with SMTP id y36-20020a056870b4a400b000f25b635b91mr5784498oap.102.1653713485191; Fri, 27 May 2022 21:51:25 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id z9-20020a544589000000b00326cb6225f8sm2418338oib.44.2022.05.27.21.51.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 May 2022 21:51:24 -0700 (PDT) Date: Fri, 27 May 2022 21:51:22 -0700 From: Noah Misch To: pgsql-bugs@lists.postgresql.org Cc: =?iso-8859-1?Q?F=E4rber=2C_Franz-Josef_=28StMUK=29?= , Tom Lane Subject: Re: Extension pg_trgm, permissions and pg_dump order Message-ID: <20220528045122.GA3228881@rfd.leadboat.com> References: <1961551.1653498155@sss.pgh.pa.us> <20220526055047.GA3153526@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220526055047.GA3153526@rfd.leadboat.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 25, 2022 at 10:50:47PM -0700, Noah Misch wrote: > BEGIN; > CREATE ROLE limitedrole; > CREATE SCHEMA ext_trgm; > CREATE EXTENSION pg_trgm SCHEMA ext_trgm; > CREATE TABLE x(y text); > ALTER TABLE x OWNER TO limitedrole; > CREATE INDEX ON x USING gist(y ext_trgm.gist_trgm_ops); > ROLLBACK; > Not too simple, no. The parts of DefineIndex() that execute user code > (e.g. DefineIndex->ComputeIndexAttrs->CheckMutability) are interspersed with > the parts that do permissions checks, like the one yielding $SUBJECT at > DefineIndex->ComputeIndexAttrs->ResolveOpClass->LookupExplicitNamespace. My > first candidate is to undo the userid switch before the ResolveOpClass() call > and restore it after. My second candidate is to pass down the userid we want > used for this sort of permissions check. Depending on the full list of call > stacks reaching permissions checks, this could get hairy. While I'd value the opportunity to work on this, there only a 50% chance I could get it done by 2022-08-01. I've set aside four hours on 2022-06-12 to see how far I get. For a 95% chance, the date would be 2023-02-01. (I've already canceled a 2022-07 vacation for the thing taking my time instead; there's nothing clearly left to cut.) If anyone would like it done faster than that, I welcome that person taking over.