--- title: "Security" id: logical-replication-security pg_version: "20devel" --- ## 29.12. Security The role used for the replication connection must have 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. In order to be able to copy the initial table data or synchronize sequences, the role used for the replication connection must have the `SELECT` privilege on a published table or sequence (or be a superuser). To create a publication, the user must have the `CREATE` privilege in the database. To create a publication using `FOR TABLE`, the user must have ownership rights on all the listed tables. To create a publication using any of `FOR ALL TABLES`, `FOR ALL SEQUENCES`, or `FOR TABLES IN SCHEMA`, the user must be a superuser. To alter a publication using `ADD TABLE`, the user must have ownership rights on all the listed tables. To alter a publication using `ADD TABLES IN SCHEMA`, the user must be a superuser. There are currently no privileges on publications. Any subscription (that is able to connect) can access any publication. Thus, if you intend to hide some information from particular subscribers, such as by using row filters or column lists, or by not adding the whole table to the publication, be aware that other publications in the same database could expose the same information. Publication privileges might be added to PostgreSQL in the future to allow for finer-grained access control. To create a subscription, the user must have the privileges of the `pg_create_subscription` role, as well as `CREATE` privileges on the database. If `SERVER` is specified, the user also must have `USAGE` privileges on the server. The subscription apply process will, at a session level, run with the privileges of the subscription owner. However, when performing an insert, update, delete, or truncate operation on a particular table, it will switch roles to the table owner and perform the operation with the table owner's privileges. Similarly, when synchronizing sequence data, it will switch to the sequence owner's role and perform the operation using the sequence owner's privileges. This means that the subscription owner needs to be able to `SET ROLE` to each role that owns a replicated table or sequence. If the subscription has been configured with `run_as_owner = true`, then no user switching will occur. Instead, all operations will be performed with the permissions of the subscription owner. In this case, the subscription owner only needs privileges to `SELECT`, `INSERT`, `UPDATE`, and `DELETE` from the target table, and does not need privileges to `SET ROLE` to the table owner. However, this also means that any user who owns a table into which replication is happening can execute arbitrary code with the privileges of the subscription owner. For example, they could do this by simply attaching a trigger to one of the tables which they own. Because it is usually undesirable to allow one role to freely assume the privileges of another, this option should be avoided unless user security within the database is of no concern. When synchronizing sequences with `run_as_owner = true`, the subscription owner similarly needs `UPDATE` privilege on the target sequence and does not need privileges to `SET ROLE` to the sequence owner. On the publisher, privileges are only checked once at the start of a replication connection and are not re-checked as each change record is read. On the subscriber, the subscription owner's privileges are re-checked for each transaction when applied. If a worker is in the process of applying a transaction when the ownership of the subscription is changed by a concurrent transaction, the application of the current transaction will continue under the old owner's privileges.