begriffs open source - ai-pg/blob - full-docs/txt/logical-replication-security.txt

   1
   2 29.11. Security #
   3
   4    The role used for the replication connection must have the REPLICATION
   5    attribute (or be a superuser). If the role lacks SUPERUSER and
   6    BYPASSRLS, publisher row security policies can execute. If the role
   7    does not trust all table owners, include options=-crow_security=off in
   8    the connection string; if a table owner then adds a row security
   9    policy, that setting will cause replication to halt rather than execute
  10    the policy. Access for the role must be configured in pg_hba.conf and
  11    it must have the LOGIN attribute.
  12
  13    In order to be able to copy the initial table data, the role used for
  14    the replication connection must have the SELECT privilege on a
  15    published table (or be a superuser).
  16
  17    To create a publication, the user must have the CREATE privilege in the
  18    database.
  19
  20    To add tables to a publication, the user must have ownership rights on
  21    the table. To add all tables in schema to a publication, the user must
  22    be a superuser. To create a publication that publishes all tables or
  23    all tables in schema automatically, the user must be a superuser.
  24
  25    There are currently no privileges on publications. Any subscription
  26    (that is able to connect) can access any publication. Thus, if you
  27    intend to hide some information from particular subscribers, such as by
  28    using row filters or column lists, or by not adding the whole table to
  29    the publication, be aware that other publications in the same database
  30    could expose the same information. Publication privileges might be
  31    added to PostgreSQL in the future to allow for finer-grained access
  32    control.
  33
  34    To create a subscription, the user must have the privileges of the
  35    pg_create_subscription role, as well as CREATE privileges on the
  36    database.
  37
  38    The subscription apply process will, at a session level, run with the
  39    privileges of the subscription owner. However, when performing an
  40    insert, update, delete, or truncate operation on a particular table, it
  41    will switch roles to the table owner and perform the operation with the
  42    table owner's privileges. This means that the subscription owner needs
  43    to be able to SET ROLE to each role that owns a replicated table.
  44
  45    If the subscription has been configured with run_as_owner = true, then
  46    no user switching will occur. Instead, all operations will be performed
  47    with the permissions of the subscription owner. In this case, the
  48    subscription owner only needs privileges to SELECT, INSERT, UPDATE, and
  49    DELETE from the target table, and does not need privileges to SET ROLE
  50    to the table owner. However, this also means that any user who owns a
  51    table into which replication is happening can execute arbitrary code
  52    with the privileges of the subscription owner. For example, they could
  53    do this by simply attaching a trigger to one of the tables which they
  54    own. Because it is usually undesirable to allow one role to freely
  55    assume the privileges of another, this option should be avoided unless
  56    user security within the database is of no concern.
  57
  58    On the publisher, privileges are only checked once at the start of a
  59    replication connection and are not re-checked as each change record is
  60    read.
  61
  62    On the subscriber, the subscription owner's privileges are re-checked
  63    for each transaction when applied. If a worker is in the process of
  64    applying a transaction when the ownership of the subscription is
  65    changed by a concurrent transaction, the application of the current
  66    transaction will continue under the old owner's privileges.