PostgreSQL: сделать схему ограниченной / неизменной?

Question

Нам нравится наша производственная среда с ограниченной / неизменяемой схемой - сторона разработки может принадлежать разработчикам и может изменяться по своему усмотрению - и нам нравится проверять изменения по мере их продвижения.

Мне интересно, может ли это быть решением для достижения этой цели:

postgres% create proddb with owner=postgres;

unixside% pg_restore --dbname=devdb [--schema-only] --no-owner proddb
/* grants to users on schema objects appear to remain intact */

/* here's the magic, I hope... */
postgres% revoke create on schema public from public;
postgres% grant usage on schema public to produser(s);

Некоторое тестирование, кажется, показывает, что пользователь в этом новом proddb может нормально взаимодействовать с таблицами (с соответствующими разрешениями) и не может изменять схему (изменить таблицу, создать таблицу, удалить таблицу и т. Д.). Но я параноик и очень новичок в Postgres, так что ...

В: Это правильно?

В: Я что-то упустил?

Большое спасибо.

Answer 1

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

Answer 2

Я забыл, в какой версии PostgreSQL добавлен синтаксис, но один из самых простых способов администрирования разрешений в PostgreSQL - через синтаксис "GRANT foo, priv ON ALL что-то в SCHEMA".

BEGIN;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA my_schema TO my_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA my_schema TO my_role;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA my_schema TO my_role;
COMMIT;

Очень удобно для проверки правильности установки разрешений.

EXECUTE for FUNCTIONS может показаться жутким, но этого не должно быть, если ваши функции не были созданы с помощью атрибута SECURITY DEFINER (и если вы используете SECURITY DEFINER, вам следует быть осторожным, поскольку вы играете с PostgreSQL версия функции "setuid"). Если вы распределите ваши TABLES по разным SCHEMAS на основе ожидаемых разрешений, это станет довольно удобным соглашением при использовании с переменной search_path.

ALTER ROLE my_role SET search_path = my_schema, auth_schema, public;
-- Avoid using the public schema (pretty please)

Где auth_schema имеет коллекцию таблиц, на которые my_role не должен иметь права прямого чтения или записи. Назначение привилегий для групп также полезно.

Вот некоторые соответствующие документы:

http://developer.postgresql.org/pgdocs/postgres/sql-grant.html

Не забывайте, что вы можете использовать "\ h GRANT" в psql, чтобы легко выяснить синтаксис или запомнить, что можно сделать со всеми объектами в схеме (поиск "IN SCHEMA").

Answer 3

Обнаружен отсутствующий элемент: sequence.

Пользователь обнаружил ошибки в своих скриптах; похожие ошибки появились в логах:

ERROR:  permission denied for sequence <sequence>

Производственная схема показала, что, хотя последовательности были созданы, они принадлежали postgres, и пользователям не предоставлялось никаких явных грантов. Согласно документации GRANT:

Предоставление разрешения для таблицы не распространяется автоматически на любые последовательности, используемые таблицей, включая последовательности, связанные со столбцами SERIAL. Разрешения на последовательность должны быть установлены отдельно.

Нашим исправлением (многословным для этой демонстрации) было найти все последовательности:

unixside% pg_dump --schema-only proddb > proddb.schema
unixside% grep -i 'create sequence' proddb.schema

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

postgres% grant select,update on <sequence> to produser(s);

Пока пользователь говорит, что он работает и ошибки в журнале прекратились ...