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 1o43B1-0000Ex-0e for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Jun 2022 16:25:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o43Az-00035T-TU for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Jun 2022 16:25:57 +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 1o43Az-00033v-Jb for pgsql-bugs@lists.postgresql.org; Wed, 22 Jun 2022 16:25:57 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o43Ax-0000li-Ap for pgsql-bugs@lists.postgresql.org; Wed, 22 Jun 2022 16:25:56 +0000 Received: by mail-pl1-x62f.google.com with SMTP id o18so8768793plg.2 for ; Wed, 22 Jun 2022 09:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QLrfJ0a27Q7d7JXph6wuOsys53JV3xt/fkLDu4peIBc=; b=Qgrh285A3lCsKpy4Ng3UDCHYjLzaNEdpJU/xkulg+n4BsX6Y0Q53QMHv0lpfZZa1Bl nBdvix5VxRoajrjHNEAPmcRryErZOhE+oOi0qD+WouJ8rAyD5ykSm4NuCBTZlf1b5CZx pDt6n4L4eECxSCxDQWuG8P398/JxS1JS4qd0I55b3fbptUZmPFcng9TUxiqtEz+sRmKB FB3aFXm5yjh9pwEhiBmd3xnt+GuKEqnE2igkSd5TLo5+MGnFCAm+Z8ZCq+FFg8PvZHbC 6MBUkjtWLUZU1E5/GaI4E1QJukvof/YIvfHtGV9qTk8Yh7U6XQ7vuWU79ej9CHuZYEgl SOIg== 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; bh=QLrfJ0a27Q7d7JXph6wuOsys53JV3xt/fkLDu4peIBc=; b=2dUn4BboGktmTRXn3rplVwhKNAowxZGT4xZ40VHud/eMtAofi6oW3rTMdMqxPtBmLk DLBY89ndPgB+viamTCgrWFBKvXLw/8BjW2S5Ne9u3GYxLj/vKqZ3uLhxtwvy52DkK4wO GZr6i3wJ6aEQrG+HWbe40O3vUX1SBgPerOMG4rIKKZ/i1o8FhOWvxwlYQABF/2nleUJS /SNygyyDE454DzJwyvGOdtBWSs1l1eim1qgZ5E2cZXzilnaxUO9ao8yFvdjz8O5+N+9/ 1ZrZA47G9QB4fpe6wdlqN0iXANn5ATceHw90FdaGvl9UQ+PSfn4tfWdvSC/yKDoppbeU 9HFA== X-Gm-Message-State: AJIora+xRPf9FxmGgCwMT/ee89nTaaEseCJ1N5XN92HdWIud6917Fw+R OalVdeolWBRGAgPxbmjqbF0= X-Google-Smtp-Source: AGRyM1uq2lkvak3JKEkPzFStBlQxqE0rJekBIuTEWR2+zJmkPQ1vYkoW6G8+ArrtFsWX4U1K+g8FGA== X-Received: by 2002:a17:903:2312:b0:16a:4a5b:a615 with SMTP id d18-20020a170903231200b0016a4a5ba615mr3500837plh.48.1655915154225; Wed, 22 Jun 2022 09:25:54 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id q4-20020a170902f78400b001641670d1adsm13079700pln.131.2022.06.22.09.25.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jun 2022 09:25:53 -0700 (PDT) Date: Wed, 22 Jun 2022 09:25:50 -0700 From: Nathan Bossart To: Noah Misch Cc: Michael Paquier , pgsql-bugs@lists.postgresql.org, =?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: <20220622162550.GA95419@nathanxps13> References: <20220529043403.GB3265235@rfd.leadboat.com> <20220531152855.GA2236210@nathanxps13> <20220603181724.GA2672350@nathanxps13> <20220606063056.GA3527347@rfd.leadboat.com> <20220609051708.GA3615673@rfd.leadboat.com> <20220613034551.GB3728437@rfd.leadboat.com> <20220616054218.GA3980475@rfd.leadboat.com> <20220621175616.GA93985@nathanxps13> <20220622033704.GA4167527@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220622033704.GA4167527@rfd.leadboat.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 21, 2022 at 08:37:04PM -0700, Noah Misch wrote: > On Tue, Jun 21, 2022 at 10:56:16AM -0700, Nathan Bossart wrote: >> On Wed, Jun 15, 2022 at 10:42:18PM -0700, Noah Misch wrote: >> > + * Identify the opclass to use. Use of ddl_userid is necessary due to >> > + * ACL checks therein. This is safe despite opclasses containing >> > + * opaque expressions (specifically, functions), because only >> > + * superusers can define opclasses. >> >> It's not clear to me why the fact that only superusers can define opclasses >> makes this safe. > > classOidP[attn] = ResolveOpClass(attribute->opclass, > atttype, > accessMethodName, > accessMethodId); > > To write the comment, I pondered how those four arguments could conceivably > lead ResolveOpClass() to locate Trojan code. Since only superusers can define > opclasses, we can assume the catalog entries of an opclass do not point to > Trojan code. (The superuser could just do the mischief directly, rather than > going to extra trouble to set a trap for later.) If you see a hole in that > thinking, please do share. Thanks for clarifying. That makes sense to me. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com