В Postgres Pro Shardman имеется набор предопределённых ролей, которые дают доступ к некоторым часто востребованным, но не общедоступным функциям и данным. Администраторы (включая роли с правами CREATEROLE) могут назначать (GRANT) эти роли пользователям и/или ролям в своей среде, таким образом открывая этим пользователям доступ к указанной функциональности и информации. Например:
GRANT pg_signal_backend TO admin_user;
Управлять членством в этих ролях следует осмотрительно, чтобы они использовались только по необходимости и только с пониманием, что они открывают доступ к закрытой информации.
Имеющиеся предопределённые роли описаны ниже. Заметьте, что конкретные разрешения для каждой из таких ролей в будущем могут изменяться по мере добавления дополнительной функциональности. Администраторы должны следить за этими изменениями, просматривая замечания к выпускам.
pg_checkpoint #pg_checkpoint позволяет выполнять команду CHECKPOINT.
pg_create_subscription #pg_create_subscription разрешает пользователям с правом CREATE для базы данных выполнять команду CREATE SUBSCRIPTION.
pg_database_owner #pg_database_owner всегда имеет ровно одного неявного члена: владельца текущей базы данных. Этой роли нельзя назначить членство в других ролях, и никакая роль не может быть членом pg_database_owner. Однако, как и любая другая роль, она может владеть объектами и получать права доступа. Следовательно, права, данные роли pg_database_owner в базе-шаблоне, приобретёт владелец каждой базы, созданной из данного шаблона. Изначально эта роль владеет схемой public, то есть владелец базы данных управляет использованием данной схемы в своей базе.
pg_maintain #pg_maintain позволяет выполнять команды VACUUM, ANALYZE, CLUSTER, REFRESH MATERIALIZED VIEW, REINDEX и LOCK TABLE для всех отношений, как будто роль имеет права MAINTAIN на эти объекты.
pg_monitorpg_read_all_settingspg_read_all_statspg_stat_scan_tables #Эти роли созданы для того, чтобы администраторы могли легко настроить роль для мониторинга сервера БД. Эти роли наделяют своих членов набором общих прав, позволяющих читать различные полезные параметры конфигурации, статистику и другую системную информацию, что обычно доступно только суперпользователям.
pg_monitor позволяет читать/выполнять различные представления и функции мониторинга. Эта роль включена в роли pg_read_all_settings, pg_read_all_stats и pg_stat_scan_tables.
pg_read_all_settings позволяет читать все конфигурационные переменные, даже те, что обычно видны только суперпользователям.
pg_read_all_stats позволяет читать все представления pg_stat_* и использовать различные расширения, связанные со статистикой, даже те, что обычно видны только суперпользователям.
pg_stat_scan_tables позволяет выполнять функции мониторинга, которые могут устанавливать блокировки ACCESS SHARE в таблицах, возможно, на длительное время
pg_read_all_datapg_write_all_data #pg_read_all_data позволяет читать все данные (таблицы, представления, последовательности), как будто роль имеет права SELECT на эти объекты и права USAGE на все схемы. Эта роль не обходит политики защиты на уровне строк (RLS). Если используется политика RLS, администратор может задать атрибут BYPASSRLS членам этой роли.
pg_write_all_data позволяет записывать все данные (таблицы, представления, последовательности), как будто роль имеет права INSERT, UPDATE и DELETE на эти объекты и права USAGE на все схемы. Эта роль не обходит политики защиты на уровне строк (RLS). Если используется политика RLS, администратор может задать атрибут BYPASSRLS членам этой роли.
pg_read_server_filespg_write_server_filespg_execute_server_program #Эти роли предназначены для того, чтобы администраторы могли выделить доверенные, но не имеющие права суперпользователей роли для доступа к файлам и запуска программ на сервере БД от имени пользователя, запускающего СУБД. Они обходят все проверки разрешений на уровне базы данных, а значит, воспользовавшись ими, можно получить права суперпользователя. Поэтому назначать их пользователям следует со всей осторожностью.
pg_read_server_files позволяет читать файлы в любом месте файловой системы, куда имеет доступ СУБД на сервере, выполняя COPY и другие команды и функции для работы с файлами.
pg_write_server_files позволяет записывать файлы в любом месте файловой системы, куда имеет доступ СУБД на сервере, выполняя COPY и другие команды и функции для работы с файлами.
pg_execute_server_program позволяет выполнять программы на сервере (от имени пользователя, запускающего СУБД) так же, как это делает команда COPY и другие команды и функции, выполняющие программы на стороне сервера.
pg_signal_autovacuum_worker #pg_signal_autovacuum_worker позволяет отправлять сигналы рабочим процессам автоочистки для отмены текущей очистки таблицы или завершения её сеанса. См. Подраздел 9.28.2.
pg_signal_backend #pg_signal_backend позволяет отправлять сигналы другим обслуживающим процессам для отмены запроса или завершения сеанса. Обратите внимание, что эта роль не позволяет отправлять сигналы процессам, принадлежащим суперпользователям. См. Подраздел 9.28.2.
pg_use_reserved_connections #pg_use_reserved_connections позволяет использовать слоты подключения, зарезервированные при помощи параметра reserved_connections.
pg_create_tablespace #pg_create_tablespace позволяет выполнять команду CREATE TABLESPACE без прав суперпользователя.
pg_manage_profiles #pg_manage_profiles позволяет выполнять команды CREATE PROFILE, ALTER PROFILE и DROP PROFILE без прав суперпользователя.
managed #Управляемая роль, которая выполняет команды на всех узлах кластера. Действие управляемой роли распространяется на весь кластер, а не на отдельную базу данных в рамках одного кластера. Её функции шире, чем у обычной роли: например, если она используется в качестве оператора, все команды выполняются глобально. Обратите внимание, что управляемый пользователь может также создать на узле любой локальный или удалённый объект.
Роли pg_monitor, pg_read_all_settings, pg_read_all_stats и pg_stat_scan_tables созданы для того, чтобы администраторы могли легко настроить роль для мониторинга сервера БД. Эти роли наделяют своих членов набором общих прав, позволяющих читать различные полезные параметры конфигурации, статистику и другую системную информацию, что обычно доступно только суперпользователям.
Единственным членом роли pg_database_owner неявным образом является владелец текущей базы данных. Как и любая другая роль, она может владеть объектами или получать права доступа. Следовательно, права, данные роли pg_database_owner в базе-шаблоне, приобретёт владелец каждой базы, созданной из данного шаблона. Роль pg_database_owner не может быть членом какой-либо роли, и в неё не могут быть явно включены члены. Изначально эта роль владеет схемой public, то есть владелец базы данных управляет использованием данной схемы в своей базе.
Роль pg_signal_backend предназначена для того, чтобы администраторы могли давать доверенным, но не имеющим прав суперпользователя ролям право посылать сигналы другим обслуживающим процессам. В настоящее время эта роль позволяет передавать сигналы для отмены запроса, выполняющегося в другом процессе, или для завершения сеанса. Однако пользователь, включённый в эту роль, не может отправлять сигналы процессам, принадлежащим суперпользователям. См. Подраздел 9.28.2.
Роли pg_read_server_files, pg_write_server_files и pg_execute_server_program предназначены для того, чтобы администраторы могли выделить доверенные, но не имеющие права суперпользователей роли для доступа к файлам и запуска программ на сервере БД от имени пользователя, запускающего СУБД. Так как эти роли могут напрямую обращаться к любым файлам в файловой системе сервера, они обходят все проверки разрешений на уровне базы данных, а значит, воспользовавшись ими, можно получить права суперпользователя. Поэтому назначать их пользователям следует со всей осторожностью.
Управлять членством в этих ролях следует осмотрительно, чтобы они использовались только по необходимости и только с пониманием, что они открывают доступ к закрытой информации.
Администраторы могут давать пользователям доступ к этим ролям, используя команду GRANT. Например:
GRANT pg_signal_backend TO admin_user;