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

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

Члены «штата» по-прежнему не могут ВЫБРАТЬ или ОБНОВИТЬ для отдельных таблиц в схеме «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_;

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

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

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

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

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

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

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

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

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

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