Document clashes between logical replication and untrusted users.

Back-patch to v10, which introduced logical replication.

Security: CVE-2020-14349

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 7c8629d74efdf7a2a9cb4b86956de6efeed358fa..3f69b7192682725a98dbca3bd627e122021a78e2 100644 (file)
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -513,11 +513,27 @@
  
   Security
 
+  
+   A user able to modify the schema of subscriber-side tables can execute
+   arbitrary code as a superuser.  Limit ownership
+   and TRIGGER 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 FOR ALL TABLES only when superusers trust
+   every user permitted to create a non-temp table on the publisher or the
+   subscriber.
+  
+
   
    The role used for the replication connection must have
-   the REPLICATION attribute (or be a superuser).  Access for the role must be
-   configured in pg_hba.conf and it must have the
-   LOGIN attribute.
+   the REPLICATION attribute (or be a superuser).  If the
+   role lacks SUPERUSER and BYPASSRLS,
+   publisher row security policies can execute.  If the role does not trust
+   all table owners, include options=-crow_security=off 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 pg_hba.conf
+   and it must have the LOGIN attribute.