数据库所有者的特权;应用程序用户


15

快速版本:

我应该发出什么命令以使数据库所有者能够访问数据库中的表,并且可以通过该所有者的帐户来完成此操作吗?


较长版本:

我正在RDS上创建数据库。我有一个使用Amazon配置的“ root”用户。

Amazon自动创建具有非常特权的组角色“ rds_superuser”,但实际上不是超级用户。

我正在为应用程序创建数据库和用户,如下所示:

create database master_integration;
CREATE ROLE master_application LOGIN ENCRYPTED PASSWORD '...' VALID UNTIL 'infinity';
GRANT ALL ON DATABASE master_integration TO GROUP rds_superuser WITH GRANT OPTION;
GRANT ALL ON DATABASE master_integration TO GROUP master_application;

\c master_integration;
ALTER DEFAULT PRIVILEGES GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ON TABLES TO rds_superuser;

我更新了此脚本,以反映Craig Ringer关于如何处理此问题的建议。

当应用程序连接(使用master_application凭据)时,它将创建(因此拥有)表。

我的问题是我无法使用管理(root)登录来运行查询,因为该用户在表上没有特权。

通过从应用程序帐户运行以下命令,我已经能够解决此问题:

GRANT ALL privileges ON ALL TABLES IN SCHEMA public to rds_superuser;

但是,将下级用户授予privs权限回给管理用户似乎很不明智。

因此...在从应用程序创建表之前或之后,是否有可以运行的命令可以确保数据库所有者可以访问数据库中的表?


重试更改默认权限后更新...

这仍然不授予对表的访问权限;我看到它在其他地方被建议使用,并且完全有意义,但是它对我不起作用。从psql shell:

master_integration=> \ddp
                           Default access privileges
      Owner       | Schema | Type  |             Access privileges             
------------------+--------+-------+-------------------------------------------
 integration_root |        | table | integration_root=arwdDxt/integration_root+
                  |        |       | rds_superuser=arwdDxt/integration_root
(1 row)

master_integration=> \dp users
                           Access privileges
 Schema | Name  | Type  | Access privileges | Column access privileges 
--------+-------+-------+-------------------+--------------------------
 public | users | table |                   | 
(1 row)

Integration_root是我的超级用户用户,而users是我数据库中的表。


更新资料

我从亚马逊的某个人那里得到了一个毫无用处的回应。

他们要求我从master_application登录名中拨打ALTER DEFAULT PRIVILEGES。尽管这可能行得通,但却无法回答我的问题(这就是我如何仅通过rds_superuser帐户来实现此目的)。

我请他们澄清这一点,他们走了。

Answers:


9

你要ALTER DEFAULT PRIVILEGES

rds_superuser为所有新表赋予默认访问权限。

这只会影响ALTER。之后创建的表。对于现有表,您必须具有GRANT权限。


我曾尝试这样做。我在原始问题中的措辞很差,我对其进行了编辑以准确显示我正在执行的命令。我做错了吗?
安迪·戴维斯

它仅影响。之后创建的表ALTER。你什么时候做的?对于现有表,您必须具有GRANT权限。
Craig Ringer 2014年

我更改了默认的privs,然后创建了表。我将再次尝试,也许是我犯了一个错误。
安迪·戴维斯

尽管看上去绝对可以解决问题,但仍然没有运气。我更新了命令,以包括其中一张表的\ ddp和\ dp的输出。
安迪·戴维斯

太奇怪了。您可以在常规(非RDS)PostgreSQL中重现该问题吗?
Craig Ringer 2014年

0

该公共模式应该对所有用户可见。您不应将公共架构的权限限制为仅一组。

因此,如果您不使用:

GRANT ALL ON SCHEMA public TO GROUP rds_superuser WITH GRANT OPTION;

您可以使用所有帐户安全地使用公共架构。

如果您不希望特定帐户弄乱您的公共架构表,请创建一个新角色(为您的应用程序的用户使用),并撤消公共架构中该特定角色的权限。就像是:

CREATE USER mywebuser WITH PASSWORD '*****';
REVOKE ALL PRIVILEGES ON SCHEMA public FROM mywebuser;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mywebuser; (or whatever rights you need to provide)

尝试这样做时,并非相反。


??A GRANT永远不能减少访问权限。我不相信。请注意,架构中的权限也不会被该架构中的新表继承,因此拥有对该public架构的访问权限并不意味着您可以在其中使用表。
克雷格·林格2014年

我终于可以尝试一下了,这对情况没有帮助。
安迪·戴维斯

我已经编辑了问题,以消除@Aleandros所指的Grant。这似乎不是问题,但我认为这是一种干扰。
安迪·戴维斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.