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中的用户可以正常地与表进行交互（使用适当的授权），并且不能更改模式（alter table，create table，drop table等）。但我很偏执，对Postgres很新，所以......

问：这是正确的吗？

问：我错过了什么吗？

非常感谢。

Answer 1

是的，这是正确的。唯一的补充是表的所有者总是可以删除或修改它。因此，如果模式中有现有表，则可能无效。

Answer 2

发现了一个缺失的元素：序列。

用户在他的脚本中发现错误;日志中出现了类似的错误：

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);

到目前为止，用户说它正在工作并且日志中的错误已经停止......

Answer 3

我忘记了PostgreSQL添加语法的版本，但是在PostgreSQL中管理权限的最简单方法之一是通过“GRANT foo，priv ON ALL something IN 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”函数的版本）。如果根据预期的权限在不同的SCHEMAS中分隔您的TABLES，那么当与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不应该具有直接的读或写权限。为GROUPS分配权限也很有用。

以下是一些相关文档：

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

不要忘记您可以在psql中使用“\ h GRANT”来轻松找出语法或记住可以对模式中的所有对象执行的操作（搜索“IN SCHEMA”）。

PostgreSQL：使模式受限制/不可更改？

3 个答案: