Предоставить все на определенной схеме в БД для групповой роли в PostgreSQL

Используя PostgreSQL 9.0, у меня есть групповая роль под названием "штат", и я хотел бы предоставить все (или определенные) привилегии этой роли для таблиц в определенной схеме. Ни одна из следующих работ

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Члены "staff" по-прежнему не могут выбрать SELECT или UPDATE для отдельных таблиц в схеме "foo" или (в случае второй команды) для любой таблицы в базе данных, если я не предоставлю все для этой конкретной таблицы.

Что я могу сделать, чтобы облегчить себе и моим пользователям жизнь?

Обновление: разобрался с помощью аналогичного вопроса на serverfault.com.

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;
Источник

2 ответа

Решение

Вы нашли сокращение для установки привилегий для всех существующих таблиц в данной схеме. Руководство разъясняет:

(но учтите, что ALL TABLES считается включать в себя представления и внешние таблицы).

Жирный акцент мой. serial столбцы реализованы с nextval() на последовательности как столбец по умолчанию и, цитируя руководство:

Для последовательностей эта привилегия позволяет использовать currval а также nextval функции.

Так что если есть serial столбцы, вы также хотите предоставить USAGE (или же ALL PRIVILEGES) по последовательностям

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Примечание: столбцы идентификаторов в Postgres 10 или более поздней версии используют неявные последовательности, которые не требуют дополнительных привилегий. (Рассмотреть вопрос об обновлении serial столбцы.)

А как насчет новых объектов?

Вам также будет интересно DEFAULT PRIVILEGES для пользователей или схем:

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Это устанавливает привилегии для объектов, созданных в будущем автоматически, но не для ранее существующих объектов.

Права по умолчанию применяются только к объектам, созданным целевым пользователем (FOR ROLE my_creating_role). Если это предложение опущено, по умолчанию выполняется текущий пользователь, выполняющий ALTER DEFAULT PRIVILEGES, Чтобы быть явным:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Также обратите внимание, что все версии pgAdmin III имеют незначительную ошибку и отображают привилегии по умолчанию на панели SQL, даже если они не применяются к текущей роли. Обязательно настройте FOR ROLE пункт вручную при копировании скрипта SQL.

Источник

Мой ответ похож на этот на ServerFault.com.

Быть консервативным

Если вы хотите быть более консервативным, чем предоставлять "все привилегии", вы можете попробовать что-то более подобное.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

Использование public там ссылается на имя схемы по умолчанию, созданной для каждой новой базы данных / каталога. Замените своим именем, если вы создали схему.

Доступ к схеме

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

Вы не заметите это требование при первом использовании Postgres. По умолчанию каждая база данных имеет первую схему с именем public, И каждому пользователю по умолчанию автоматически предоставляются права "использования" для этой конкретной схемы. При добавлении дополнительной схемы вы должны явно предоставить права на использование.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Выдержка из документа Postgres:

Для схем разрешает доступ к объектам, содержащимся в указанной схеме (при условии, что соблюдаются и собственные требования к привилегиям объектов). По сути, это позволяет получателю "искать" объекты в схеме. Без этого разрешения все еще можно увидеть имена объектов, например, путем запроса системных таблиц. Кроме того, после отзыва этого разрешения у существующих бэкэндов могут быть операторы, которые ранее выполняли этот поиск, так что это не совсем безопасный способ предотвратить доступ к объекту.

Для получения дополнительной информации см. Вопрос, что именно делает GRANT USAGE ON SCHEMA?, Обратите особое внимание на ответ эксперта Postgres Craig Ringer.

Существующие объекты против будущего

Эти команды влияют только на существующие объекты. Таблицы и тому подобное, которые вы создадите в будущем, получат привилегии по умолчанию, пока вы не выполните эти строки выше. Посмотрите другой ответ Эрвина Брандштеттера об изменении значений по умолчанию, влияющих на будущие объекты.

Источник
Другие вопросы по тегам