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