mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Document clashes between logical replication and untrusted users.

Browse Source 
Back-patch to v10, which introduced logical replication.

Security: CVE-2020-14349
This commit is contained in:
Noah Misch 2020-08-10 09:22:54 -07:00
parent 11da97024a
commit cec57b1a0f
1 changed files with 19 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/src/sgml/logical-replication.sgml
View File

@ -513,11 +513,27 @@
<sect1 id="logical-replication-security">
<title>Security</title>
<para>
A user able to modify the schema of subscriber-side tables can execute
arbitrary code as a superuser. Limit ownership
and <literal>TRIGGER</literal> privilege on such tables to roles that
superusers trust. Moreover, if untrusted users can create tables, use only
publications that list tables explicitly. That is to say, create a
subscription <literal>FOR ALL TABLES</literal> only when superusers trust
every user permitted to create a non-temp table on the publisher or the
subscriber.
</para>
<para>
The role used for the replication connection must have
the <literal>REPLICATION</literal> attribute (or be a superuser). Access for the role must be
configured in <filename>pg_hba.conf</filename> and it must have the
<literal>LOGIN</literal> attribute.
the <literal>REPLICATION</literal> attribute (or be a superuser). If the
role lacks <literal>SUPERUSER</literal> and <literal>BYPASSRLS</literal>,
publisher row security policies can execute. If the role does not trust
all table owners, include <literal>options=-crow_security=off</literal> in
the connection string; if a table owner then adds a row security policy,
that setting will cause replication to halt rather than execute the policy.
Access for the role must be configured in <filename>pg_hba.conf</filename>
and it must have the <literal>LOGIN</literal> attribute.
</para>
<para>