原作者：陆凯

• 引言
• 用户和角色
• 授权场景
• 权限查询
• 用户删除
• 总结

引言

在MogDB数据库中，除了缺省的管理员用户具有所有的权限，其他角色在创建时几乎不会附带任何显式权限，后期可以根据需求对普通角色进行授权，实现对象权限的细粒度控制，保障数据安全。

用户和角色

用户（user）和角色（role）在本质上是不同的概念，但是在实际场景中我们几乎不会刻意划分两者（本文中也不刻意区分）。它们比较大的区别就是用户在创建时会被隐式赋予login登录权限并创建同名schema。

解释create user u1 with password 'Enmotech@123';
#等同于
create role u1 with login password 'Enmotech@123';
create schema authorization u1;

授权场景

1.将系统权限授权给角色或用户

系统权限又称为用户属性，包括SYSADMIN、CREATEDB、CREATEROLE、AUDITADMIN、MONADMIN、OPRADMIN、POLADMIN、LOGIN等。

系统权限一般在创建用户时就指定（已存在的可以alter user）。其中，SYSADMIN权限可以通过GRANT ALL PRIVILEGE授予。

2.将数据库对象授权给角色或用户
数据库对象往往包括一系列的权限，可以通过grant来执行授权，对象的owner缺省具有该对象上的所有权限，出于安全考虑所有者可以舍弃部分权限，但ALTER、DROP、COMMENT、INDEX、VACUUM以及对象的可再授予权限属于所有者固有的隐式权限，需要注意的是，grant仅仅能对已存在的数据库对象进行授权，无法对后续创建的对象同时自动赋予相关权限，这一点可以使用ALTER DEFAULT PRIVILEGES命令实现：

#u1用户在u1模式下新建的表会自动赋予u2查询权
alter default privileges for user u1 in schema u1 grant select on tables to u2;

3.用户之间的授权
因为用户代表着一系列权限的载体（系统权限和对象权限），对于普通用户而言，直接继承其他用户的权限往往更加便捷

#将u2添加为u1的组成员，享受u1已有的对象权限，但是不包括u1已有的系统权限
grant u1 to u2

回收权限revoke可以撤销已经授权的行为：

revoke 权限/角色 from user ；

权限查询

查询用户具有的系统权限可以通过元命令：\du、\dg或直接通过pg_authid查看

查询用户已有数据库对象（表）的权限可以通过information_schema下的权限视图table_privileges或者元命令\ddp

SELECT grantee, table_catalog, table_schema, table_name, privilege_type FROM information_schema.table_privileges WHERE grantee = 'username';

用户删除

用户的删除往往意味着权限的回收，如果用户拥有某些对象的权限或者对象所有者为该用户，直接删除用户是不被允许的：

这种场景下就需要级联删除drop user xx cascade，级联删除会回收该用户对象权限的同时会删除owner为该用户的数据库对象，故删除用户的操作需要谨慎进行，判定相关对象是否能被附带删除，如若不能，必须修改相关对象的owner到其他用户之后再删除用户，还有一种方式是通过drop owned by user来先执行用户的依赖删除，进而可直接删除用户

总结

在mogdb中，用户和角色是作为一系列系统权限和对象权限的载体，常见的系统权限如SYSADMIN、CREATEDB、CREATEROLE、AUDITADMIN、MONADMIN，常见的对象权限如create、alter、drop、usage、comment，合理的授权是对象细粒度控制的安全准则之一，对不需要的权限需要进行及时的回收。