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.