From: Antonin Houska <ah@cybertec.at>
To: "Euler Taveira" <euler@eulerto.com>
cc: "Amit Kapila" <amit.kapila16@gmail.com>,
    "Peter Eisentraut" <peter.eisentraut@enterprisedb.com>,
    "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Privileges on PUBLICATION
In-reply-to: <d96103fe-99e2-4119-bd76-952d326b7539@www.fastmail.com>
References: <20330.1652105397@antos>
 <8a00e0e1-dc4e-422c-9dcf-664b16b18625@www.fastmail.com>
 <CAA4eK1Lya6BoMa1m8cTZrQ8KvABQpn3EsHDKRurz8UJeHsGnZw@mail.gmail.com>
 <2810.1652171844@antos>
 <d96103fe-99e2-4119-bd76-952d326b7539@www.fastmail.com>
Comments: In-reply-to "Euler Taveira" <euler@eulerto.com>
   message dated "Thu, 12 May 2022 09:48:28 -0300."
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Date: Fri, 13 May 2022 08:36:37 +0200
Message-ID: <5859.1652423797@antos>
Archived-At: <https://www.postgresql.org/message-id/5859.1652423797%40antos>
Precedence: bulk

--=-=-=
Content-Type: text/plain

Euler Taveira <euler@eulerto.com> wrote:

> On Tue, May 10, 2022, at 5:37 AM, Antonin Houska wrote:
> 
>  My understanding is that the rows/columns filtering is a way for the
>  *publisher* to control which data is available to particular replica. From
>  this point of view, the publication privileges would just make the control
>  complete.
> 
> I agree. IMO it is a new feature. We already require high privilege for logical
> replication. Hence, we expect the replication user to have access to all data.
> Unfortunately, nobody mentioned about this requirement during the row filter /
> column list development; someone could have written a patch for GRANT ... ON
> PUBLICATION.

I can try that for PG 16, unless someone is already working on it.

> I understand your concern. Like I said in my last sentence in the previous
> email: it is a fine-grained access control on the publisher. Keep in mind that
> it will *only* work for non-superusers (REPLICATION attribute). It is not
> exposing something that we didn't expose before. In this particular case, there
> is no mechanism to prevent the subscriber to obtain data provided by the
> various row filters if they know the publication names. We could probably add a
> sentence to "Logical Replication > Security" section:
> 
> There is no privileges for publications. If you have multiple publications in a
> database, a subscription can use all publications available.

Attached is my proposal. It tries to be more specific and does not mention the
absence of the privileges explicitly.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=publication_filtering_warning.diff

diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml
index 1a828e8d2ff..b74ba625649 100644
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/doc/src/sgml/ref/create_publication.sgml
@@ -94,6 +94,16 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
       list is specified, it must include the replica identity columns.
      </para>
 
+     <warning>
+      <para>
+       If you are using the <literal>WHERE</literal> clause or the column list
+       to omit some table data from the replication for security reasons,
+       please make sure that the same data is not exposed via other
+       publications which contain the same table and have different (or
+       none) <literal>WHERE</literal> clause or column list.
+     </para>
+     </warning>
+
      <para>
       Only persistent base tables and partitioned tables can be part of a
       publication.  Temporary tables, unlogged tables, foreign tables,

--=-=-=--