学习Greenplum的资源授权

Posted 2020-09-02 sdjnfangjx

用户/角色在整个数据库实例中是全局的。

用户和角色区别是用户默认有LOGIN权限，其他同。

在系统初始化时有个预定的超级用户，操作系统用户名,比如gpadmin。

每个数据库的逻辑结构对象都有一个所有者，所有者默认拥有所有权限，不需要重新赋予。

删除和任意修改它的权利不能赋予别人，为所有者固有，不能被赋予或撤销。

可以把操作该对象的权限赋予别人。

 

授权和撤销授权 用命令GRANT  REVOKE

 

权限的总结

    权限按如下几个层次进行管理：

1） 首先管理赋予在用户特殊属性上的权限

2） 在数据库上的权限

3） 在数据库中创建模式的权限

4） 在模式中创建数据库对象的权限，表，索引等

5） 表的增删改查的权限

6） 操作表中某些字段的权限

 

管理赋予在用户特殊属性上的权限

验证结论：

1） user的 Superuser与createuser属性不能同时拥有。

2） 有superuser属性的用户实际可以创建库和创建用户，且nocreateuser nocreatedb 对superuser属性没有约束。

3） create role创建用户，alter role修改用户属性。删除用户drop role，同理删除数据库是drop database;

4） 拥有资源的用户不能被drop，提示错误。但是资源可以被superuser drop掉。

5） 修改用户属性用alter role

 

 

在数据库上的权限

    Gpadmin创建一个数据库，依次授予某用户 CREATE CONNECT TEMPORARY TEMP 的权限。验证各选项的作用。

    创建用户tu1 ,赋予对testdb数据库CREATE权限，则可以在testdb下创建schema;

        # grant create on database testdb to tu1;

    撤销用户的connect权限

        # revoke connect on database testdb from tu1;

验证结论：

1） 实际可以使用控制的权限是CREATE。CONNECT，TEMP即使提示取消权限成功了，仍可以CONNECT和创建临时表。

2） 属性（nosuperuser,nocreatedb,nocreaterole）的用户默认情况下可以connect数据库。

不可以创建schema。

可以创建temporary table ，自动生成临时的schema，在会话结束后自动销毁。

可以在public schema中创建表。

不能在owner为其他用户的schema下创建表。

3） 数据库的CREATE权限，控制是否可以在库中创建Schema

4） 通过身份验证的用户总有CONNECT库的权限。即使是通过REVOKE撤销CONNECT，也能正常连接数据库。

5） 用户总有创建TEMP表的权限。即使是通过REVOKE撤销TEMP，也能创建临时表。

 

 

在模式上的权限

    创建一个tu1所有的schema tu1shema;创建用户tu2;

    验证tu2字tu1schema中创建表。

赋予USAGE权限看是否有变化。

    # grant usage on schema tu1schema to tu2;

赋予CREATE权限看是否有变化。

        # grant create on schema tu1schema to tu2;

验证结论：

1） 如果要在别人的schema中创建自己的表，需要用户对该shema有CREATE，USAGE权限，才可以对表和数据有足够权限。

2） 用户默认无法在owner为别个用户的schema中创建表。

3） 用户默认无法看到owner为别个用户的schema中的表，注意设置search_path 。（\dt命令查看）。

4） 赋予USAGE权限后可以看到owner为别个用户的schema中的表，但无法在里面创建表。

5） 赋予CREATE权限后可以在别个用户的schema中创建表，但如果没有USAGE权限，仍无法看到表，无法查询表中的数据，也无法更改表，即使owner是你也不行。再赋予USAGE后可以查询自己创建的表，可以更改自己创建的表，但无法查询别人的表。

6）  

 

在表上的权限

    Q:Tu1的schema中的表，是否可以赋予tu2 对表中数据select的权限，而无需对shema赋权限即可做操作呢。

    当前tu2对tu1schema没有任何权限。

        # grant select on tu1schema.table1 to tu2;

    验证 testdb=> select * from tu1schema.table1;

ERROR:  permission denied for schema tu1schema

 

    赋予tu2对tu1schema的USAGE权限。再查询成功。

    赋予增删改权限后才能增删改。

# grant select,update,delete,insert on tu1schema.table1 to tu2;

验证结论：

1） 需要逐级授权，如果需要对表有权限，那么至少也得在表所属的schema有权限。

2） 表上面有  SELECT ,INSERT,UPDATE,DELETE授权。

 

在sequence上的权限

#create sequence sequid owned by table2.uid;

    这样创建了一个sequence，有什么用呢？并不会自动给table2.uid赋值。

    使用时仍是用  insert into **  values(nextval(‘seqid’),…

 

    #grant UPDATE on sequence sequid to tu2;

#revoke UPDATE on sequence sequid from tu2;

验证结论：

1） sequence与表同级，提供顺序的序列号。

2） 其他用户调用nextval(‘seqname’)需要有UPDATE权限。需要对sequence所属的schema有USAGE权限。

3） 从\h grant 看到SEQUENCE有 USAGE,SELECT,UPDATE权限，但是测试发现只要有UPDATE权限就可以调用获取sequence的值。

4）  

 

在视图上的权限

验证结论：

         没有在视图上的权限，应该是在视图对应的基础表上设置权限。理应如此。

 

在函数上的权限

         函数只有EXECUTE权限。和表属于同一层。

         testdb=# grant execute on function tu1schema.proc1() to tu2;

GRANT

testdb=# revoke execute on function tu1schema.proc1() from tu2;

REVOKE

验证结论：

1）  对函数的GRANT和REVOKE测试是不起作用。

2）  在函数所属的schema层有USAGE权限即可执行。