From: Antonin Houska <ah@cybertec.at>
To: Euler Taveira <euler@eulerto.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Privileges on PUBLICATION
Date: Fri, 13 May 2022 08:36:37 +0200
Message-ID: <5859.1652423797@antos> (raw)
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>
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.comAttachments:
[text/x-diff] publication_filtering_warning.diff (986B, ../5859.1652423797@antos/2-publication_filtering_warning.diff)
download | inline diff:diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgmlindex 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,
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, euler@eulerto.com, amit.kapila16@gmail.com, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Privileges on PUBLICATION
In-Reply-To: <5859.1652423797@antos>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox