В роли, используемой для соединения репликации, должен быть установлен атрибут REPLICATION (или роль должна быть суперпользователем). Если роли не хватает атрибутов SUPERUSER и BYPASSRLS, политики защиты строк издателя могут выполняться. Если роль не доверяет всем владельцам таблиц, включите options=-crow_security=off в строку подключения; если владелец таблицы затем добавляет политику защиты строк, эта настройка приведет к остановке репликации вместо выполнения политики. Доступ для роли должен быть настроен в файле pg_hba.conf, и у нее должен быть атрибут LOGIN.

Для того чтобы иметь возможность копировать начальные данные таблицы, роль, используемая для соединения репликации, должна иметь привилегию SELECT на опубликованной таблице (или быть суперпользователем).

Для создания публикации пользователь должен иметь привилегию CREATE в базе данных.

Чтобы добавить таблицы в публикацию, пользователь должен иметь права владения таблицей. Чтобы добавить все таблицы в схеме в публикацию, пользователь должен быть суперпользователем. Чтобы создать публикацию, которая автоматически публикует все таблицы или все таблицы в схеме, пользователь должен быть суперпользователем.

В настоящее время привилегии на публикации отсутствуют. Любая подписка (которая может подключиться) может получить доступ к любой публикации. Таким образом, если вы намерены скрыть некоторую информацию от конкретных подписчиков, например, используя фильтры строк или списки столбцов, или не добавляя всю таблицу в публикацию, имейте в виду, что другие публикации в той же базе данных могут раскрыть ту же информацию. Привилегии на публикации могут быть добавлены в Tantor BE в будущем для обеспечения более детального контроля доступа.

Чтобы создать подписку, пользователь должен иметь привилегии роли pg_create_subscription, а также привилегии CREATE на базе данных.

Процесс применения подписки будет на уровне сессии выполняться с привилегиями владельца подписки. Однако при выполнении операции вставки, обновления, удаления или усечения на конкретной таблице он переключится на роль владельца таблицы и выполнит операцию с привилегиями владельца таблицы. Это означает, что владелец подписки должен иметь возможность SET ROLE для каждой роли, которая владеет реплицируемой таблицей.

Если подписка была настроена с run_as_owner = true, то переключение пользователя не произойдет. Вместо этого все операции будут выполняться с разрешениями владельца подписки. В этом случае владельцу подписки нужны только привилегии на SELECT, INSERT, UPDATE и DELETE из целевой таблицы, и не нужны привилегии на SET ROLE для владельца таблицы. Однако это также означает, что любой пользователь, который владеет таблицей, в которую происходит репликация, может выполнять произвольный код с привилегиями владельца подписки. Например, они могут сделать это просто прикрепив триггер к одной из таблиц, которыми они владеют. Поскольку обычно нежелательно позволять одной роли свободно принимать привилегии другой, этот вариант следует избегать, если безопасность пользователей в базе данных не имеет значения.

На издателе привилегии проверяются только один раз при установлении соединения репликации и не проверяются повторно при чтении каждой записи изменений.

На подписчике привилегии владельца подписки перепроверяются для каждой транзакции при ее применении. Если рабочий процесс находится в процессе применения изменения к транзакции, когда владение подпиской изменяется параллельной транзакцией, применение текущей транзакции будет продолжено с использованием привилегий предыдущего владельца.