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 1sgmV6-007qi0-A7 for pgsql-general@arkaria.postgresql.org; Wed, 21 Aug 2024 14:39:52 +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 1sgmV3-00BpXt-Kf for pgsql-general@arkaria.postgresql.org; Wed, 21 Aug 2024 14:39:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgmV3-00BpXk-9f for pgsql-general@lists.postgresql.org; Wed, 21 Aug 2024 14:39:49 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgmV0-000n3j-7g for pgsql-general@lists.postgresql.org; Wed, 21 Aug 2024 14:39:49 +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 47LEdiiM1777286; Wed, 21 Aug 2024 10:39:45 -0400 From: Tom Lane To: Dean Rasheed cc: jian he , pgsql-general list Subject: Re: security invoker review need full select (all columns) to do DML? In-reply-to: References: Comments: In-reply-to Dean Rasheed message dated "Wed, 21 Aug 2024 13:26:49 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1777284.1724251184.1@sss.pgh.pa.us> Date: Wed, 21 Aug 2024 10:39:44 -0400 Message-ID: <1777285.1724251184@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > The user must have select permissions on all columns selected by the > subquery/view, because we don't go through the outer query to check > which columns are actually referred to. Now maybe we could, but I > suspect that would be quite a lot of effort because you'd need to be > sure that the column wasn't referred to anywhere in either the outer > query or the subquery itself (e.g., in WHERE clauses, etc.). I'd argue that we should check that permission regardless, and are probably required to by the SQL spec. You don't normally get to escape permission checks when bits of the query are optimized away. (This is why permission checks are done on the range table not the plan tree.) regards, tom lane