Le rôle utilisée pour la réplication doit avoir l'attribut
REPLICATION
(ou être un superutilisateur). Si le rôle ne
dispose pas des attributs SUPERUSER
et
BYPASSRLS
, les politiques de sécurité niveau ligne du
publieur peuvent s'exécuter. Si le rôle n'a pas confiance en tous les
propriétaires de tables, incluez
options=-crow_security=off
dans la chaîne de
connexion ;: si un propriétaire de table ajoute ensuite une politique de
sécurité de ligne, cette configuration imposera un arrêt de la réplication
plutôt qu'une exécution de la politique. L'accès de ce rôle à l'instance doit
avoir été déclaré dans pg_hba.conf
et ce rôle doit avoir
l'attribut LOGIN
.
Pour être capable de copier les données originales de la table, le rôle
utilisé pour la connexion de réplication doit avoir le droit
SELECT
sur une table publiée (ou être un
superutilisateur).
Pour créer une publication, l'utilisateur doit avoir le droit
CREATE
pour la base de données.
Pour ajouter des tables à une publication, l'utilisateur doit être
propriétaire de ces tables. Pour ajouter toutes les tables d'un schéma dans
une publication, l'utilisateur doit avoir l'attribut
SUPERUSER
. Pour créer une publication qui publie toutes
les tables ou toutes les tables d'un schéma automatiquement, l'utilisateur
doit avoir l'attribut SUPERUSER
.
Actuellement, il n'y a aucun droit sur les abonnements. Tout abonnement (qui est capable de se connecter) peut accéder à n'importe quelle publication. Ainsi, si vous avez l'intention de cacher certaines informations à certains abonnés, en utilisant le filtrage de ligne ou les listes de colonnes, ou en n'ajoutant pas la totalité de la table à la publication, soyez averti que les autres publications dans la même base de données pourront exposer les mêmes informations. Les droits de publication pourront être ajoutés à PostgreSQL dans le futur pour permettre un contrôle d'accès plus fin.
Pour créer un abonnement, l'utilisateur doit avoir les droits du
rôle pg_create_subscription
ainsi que le droit
CREATE
sur la base de données.
Le processus d'application de l'abonnement va, au niveau de la session, s'exécuter
avec les droits du propriétaire de l'abonnement. Cependant, quand une opération
d'insertion, de mise à jour, de suppression ou de troncation est effectuée sur
un table donnée, le rôle sera interverti avec celui du propriétaire de la table
et l'opération effectuée avec les droits du propriétaire de la table.
Cela signifie que le propriétaire de l'abonnement doit pouvoir faire un
SET ROLE
sur chacun des rôles propriétaires des tables répliquées.
Si l'abonnement a été configuré avec run_as_owner = true
,
alors aucun changement d'utilisateur ne sera possible. À la place,
les opérations seront effectuées avec les droits du propriétaire de l'abonnement.
Dans ce cas, le propriétaire de l'abonnement nécessite seulement des droits
pour SELECT
, INSERT
,
UPDATE
et DELETE
sur les tables cibles,
et n'a pas besoin de droits pour faire un SET ROLE
sur
les propriétaires des tables. Cependant, cela implique aussi que n'importe
quel utilisateur propriétaire de table sur laquelle la réplication s'applique,
pourra exécuter du code arbitrairement avec les droits du propriétaire de
l'abonnement. Par exemple, ils pourront effectuer cela simplement en
attachant un trigger à une des tables dont ils sont propriétaires.
Parce qu'il est fortement indésirable de permettre à un rôle d'assumer librement
les droits d'un autre, cette option devrait être évitée sauf si la sécurité
de la base de données n'est pas un problème.
Sur le publieur, les droits sont vérifiés uniquement au démarrage de la connexion de réplication et ne sont pas vérifiés de nouveau à chaque fois qu'un enregistrement de changement est lu.
Sur l'abonné, les droits du propriétaire de la souscription sont vérifiés à chaque application d'une transaction. Si un processus worker est en cours de traitement pour appliquer une transaction au moment où le propriétaire de la souscription est changé dans une transaction concurrente, l'application de la transaction en cours continuera sous les droits de l'ancien propriétaire.