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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1n6FfG-0005Pm-LH
	for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Jan 2022 17:38:02 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1n6FfF-00070R-Fw
	for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Jan 2022 17:38:01 +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 <tgl@sss.pgh.pa.us>)
	id 1n6FfF-00070I-6h
	for pgsql-hackers@lists.postgresql.org; Sat, 08 Jan 2022 17:38:01 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1n6FfB-0001GH-6e
	for pgsql-hackers@postgresql.org; Sat, 08 Jan 2022 17:38:00 +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 208HbnmO1502450;
	Sat, 8 Jan 2022 12:37:49 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: Amit Kapila <amit.kapila16@gmail.com>,
        Mark Dilger <mark.dilger@enterprisedb.com>,
        Andrew Dunstan <andrew@dunslane.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>
Subject: Re: Non-superuser subscription owners
In-reply-to: <3c86885b0facc66eede94113123c1c3be39837fe.camel@j-davis.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com> <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net> <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com> <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com> <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com> <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com> <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com> <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com> <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com> <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com> <CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com> <CC5DAC9C-F767-4256-BFEF-32D5A566D254@enterprisedb.com> <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com> <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com> <92BEDE2A-8043-4F50-9BD8-46977A9A2972@enterprisedb.com> <CAA4eK1L3-qAtLO4sNGaNhzcyRi_Ufmh2YPPnUjkROBK0tN=x=g@mail.gmail.com> <fbe510fe68873607e9d2e1e0fc699a!
 cb9a50bbec.camel@j-davis.com> <CAA4eK1LjheLm0UrKgqiEf+62-FcLYBnt+Ww2n-5L9ao=_2gDqg@mail.gmail.com> <3c86885b0facc66eede94113123c1c3be39837fe.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Sat, 08 Jan 2022 09:14:59 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1502448.1641663469.1@sss.pgh.pa.us>
Date: Sat, 08 Jan 2022 12:37:49 -0500
Message-ID: <1502449.1641663469@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/1502449.1641663469%40sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> I'm not sure I follow the reasoning. Are you saying that, to logically
> replay a simple DELETE, the subscription owner should have SELECT
> privileges on the destination table?

We consider that DELETE WHERE <condition> requires SELECT privilege
on the column(s) read by the <condition>.  I suppose that the point
here is to enforce the same privilege checks that occur in normal
SQL operation, so yes.

> Is there a way that a subscription owner could somehow exploit a DELETE
> privilege to see the contents of a table on which they have no SELECT
> privileges?

BEGIN;
DELETE FROM tab WHERE col = 'foo';
-- note deletion count
ROLLBACK;

Now you have some information about whether "col" contains 'foo'.
Admittedly, it might be a pretty low-bandwidth way to extract data,
but we still regard it as a privilege issue.

			regards, tom lane