我试图授予一个给定的数据库的所有表的所有特权给一个新的postgres用户(不是所有者)。 看来, GRANT ALL PRIVILEGES ON DATABASE my_db TO new_user;
不这样做。 成功运行这个命令(作为postgres用户)后,我得到以下为new_user:
$ psql -d my_db my_db => SELECT * FROM a_table_in_my_db; ERROR: permission denied for relation a_table_in_my_db
两个问题:
1)上面的命令做了什么,然后,如果没有授予my_db上所有表的所有权限?
2)将所有表的所有权限授予用户的正确方法是什么? (包括将来创build的所有表格)
您的问题的答案来自在线PostgreSQL 8.4文档 。
授予数据库上的所有权限将数据库上的CREATE
, CONNECT
和TEMPORARY
权限授予angular色(用户适当地称为angular色 )。 这些权限实际上都不允许angular色从表中读取数据; 在这个表上的SELECT
权限是必需的。
我不确定是否有一种“适当”的方式将所有表上的所有权限授予angular色。 确保给定angular色的最佳方式是在表上拥有所有权限,以确保angular色拥有该表。 默认情况下,每个新创build的对象都由创build它的angular色所有,所以如果您希望某个angular色在表上拥有所有权限,请使用该angular色创build它。
PostgreSQL 9.0引入了几乎所需的以下语法:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;
庸俗的是,如果你在默认的“公共”模式之外的架构中创build表格,这个GRANT
将不适用于它们。 如果你使用非公共模式,你将不得不分别授予这些模式的权限。
可以设置多个login来充当数据库所有者:
create role dbowner nologin
alter database mydb owner dbowner
grant dbowner to user1, user2
现在,如果用户1或用户2login,他们拥有“mydb”的所有权限,不需要任何进一步的授权。
不过,我会仔细考虑这个解决scheme。 您的Web应用程序使用这些login名之一是很诱人的,以避免在架构更新时创build额外的授予的痛苦,但您正在以这种方式删除非常有用的保护forms。 如果您确实需要多个“pipe理员”,请使用上述解决scheme,但请坚持使用上述“正常使用”应用程序的login名中的“授予所有模式表上的所有权限”模式。