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

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

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

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

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

Обновление. Выясните это с помощью аналогичного вопроса на serverfault.com .

 GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff; 

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

(но учтите, что 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. По умолчанию каждая firebase database имеет первую схему с именем public . И каждый пользователь по умолчанию автоматически получает права использования на эту конкретную схему. При добавлении дополнительной схемы вы должны явно предоставить права использования.

 GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ; 

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

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

Для более подробного обсуждения см. Вопрос, что именно делает GRANT USGE на SCHEMA? , Обратите особое внимание на ответ эксперта Postgres Крейга Рингера .

Существующие объекты в сравнении с будущим

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

Interesting Posts

Как заставить ssh войти в качестве нужного пользователя?

JSON и работа с невыполненными полями

Пакетный файл. Удалить все файлы и папки в каталоге

Есть ли условный тернарный оператор в VB.NET?

Может ли панель разблокировки OS X запускать логин, похожий на loginwindow?

Как элегантно игнорировать некоторые возвращаемые значения функции MATLAB?

Как это возможно? Сервис работает неограниченно, а также разрешает привязку к андроиду?

Значки разного размера на рабочем столе?

Как изменить переменную, к которой относится ссылка C ++?

Как сохранить данные двух камер, но не повлиять на скорость их получения?

Комбинация клавиш быстрого доступа Outlook для перемещения сообщения в другую папку

Многостраничная электронная почта с текстом и календарем: Outlook не распознает ics

Зеркало / Резервное копирование из SSH / SFTP в Windows

Альтернатива Wget / cURL, родная Windows?

Почему мои жесткие диски не работают?

Давайте будем гением компьютера.