项目经验分享｜openGauss 陈贤文：受益于开源，回馈于开源

本文主要是介绍项目经验分享｜openGauss 陈贤文：受益于开源，回馈于开源，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

开源之夏

项目经验分享

2023 #08

# 关于 openGauss 社区

openGauss是一款开源关系型数据库管理系统，采用木兰宽松许可证v2发行。openGauss内核深度融合华为在数据库领域多年的经验，结合企业级场景需求，持续构建竞争力特性。同时openGauss也是一个开源的数据库平台，鼓励社区贡献、合作。

官网： opengauss.org
# 项目基本信息

项目名称：openGauss权限扫描

项目导师：崔永泉

项目描述：根据openGauss的数据库配置和用户权限，检查数据库中是否存在违规操作的可能和安全隐患。

# openGauss-安全管理机制笔记 主要内容： openGauss数据库权限管理模型、权限规划示例、权限识别项目具体实施方法。 openGauss数据库权限管理模型 由于数据库中存储着大量重要数据和各类敏感信息，并且为持有不同权限的合法用户提供数据共享服务，这就要求数据库具备完善的安全防御机制来抵抗来自内部和外部的恶意攻击，以保障数据不丢失、隐私不泄露以及数据不被篡改等。当前openGauss数据库已经构建了纵深防御的安全体系，保障数据库在应用中的安全。完善的权限管理机制可以有效阻断恶意用户的越权操作。 常见的权限控制模型有三种：基于策略的访问控制模型，基于角色的访问控制模型以及基于会话和角色的访问控制模型。openGauss数据库采用基于角色的权限访问控制模型(RBAC)，利用角色来组织和管理权限，能够大大简化对权限的授权管理。借助角色机制，当给一组权限相同的用户授权时，只需将权限授予角色，再将角色授予这组用户即可，不需要对用户逐一授权。而且利用角色权限分离可以很好地控制不同用户拥有不同的权限，相互制约达到平衡。

基于角色的权限访问控制模型(RBAC)

RBAC思想简单地说，一个用户拥有若干角色，每一个角色拥有若干权限，每一个角色拥有若干个菜单，这样，就构造成“用户-角色-权限”、“角色-菜单” 的授权模型。在这种模型中，用户与角色、角色与权限、角色与菜单之间构成了多对多的关系。 在openGauss数据库中，用户和角色是基本相同的概念，唯一的区别是在创建角色的时默认没有LOGIN权限，也不会自动创建同名的模 ，也就是说一个拥有LOGIN权限的角色可以被认为是一个用户。在以下的介绍中我们统一通过用户(USER) 来连接、访问数据库以及

执行SQL，通过角色（ROLE）来组织和管理权限。我们通过将不同的权限打包成角色授予用户，使得用户获得该角色中的所有权限。同时通过改变角色的权限，该角色所包含的所有成员的权限也会被自动修改。

在openGauss数据库系统中权限分为两种：系统权限和对象权限。

• 系统权限是指系统规定用户使用数据库的权限，比如登录数据库、创建数据库、创建用户/角色、创建安全策略等。

• 对象权限是指在数据库、模式、表、视图、函数等数据库对象上执行特殊动作的权限，不同的对象类型与不同的权限相关联，比如数据库的连接权限，表的查看、更新、插入等权限，函数的执行权限等。基于特定的对象来描述对象权限才是有意义的。

• 系统权限

系统权限又称用户属性，具有特定属性的用户会获得指定属性所对应的权限。系统权限无法通过角色（ROLE）被继承。在创建用户或角色时可以通过SQL语句CREATE ROLE/USER指定用户具有某些属性，或者通过ALTER ROLE/USER的方式给用户/角色添加用户属性或取消用户属性。

openGauss数据库支持如下系统权限的授予和回收：

openGauss提供SQL语句CREATE/ALTER ROLE/USER实现系统权限的授予和回收，示例如下：

#例1：创建角色role1，同时授予role1创建数据库的权限 openGauss=# CREATE ROLE role1 WITH CREATEDB password 'openGauss@2021'; CREATE ROLE
#例2：授予角色role1监控管理员的权限，同时取消创建数据库的权限 openGauss=# ALTER ROLE role1 WITH MONADMIN NOCREATEDB; ALTER ROLE
#例3：查看系统表pg_authid或系统视图pg_roles获取角色role1的相关信息 openGauss=# SELECT rolname,rolcreatedb,rolmonitoradmin FROM pg_authid WHERE rolname= 'role1'; rolname | rolcreatedb | rolmonitoradmin ---------+-------------+----------------- role1 | f | t (1 row)

• 对象权限
  

对象所有者缺省具有该对象上的所有操作权限，比如修改、删除对象的权限，查看对象的权限，将对象的操作权限授予其他用户，或撤销已经授予的操作权限等。其中对象的ALTER、 DROP、COMMENT、INDEX、VACUUM以及对象的可再授予权限属于所有者固有的权限，隐式拥有。但对象所有者可以撤消自己的普通权限，例如，使表对自己以及其他人都只可读。
对象权限可以通过角色（ROLE）被继承，这样方便用户将这些单个的权限打包成一个角色进行权限管理。openGauss数据库针对每一类数据库对象支持如下对象权限：

openGauss提供SQL语句GRANT/REVOKE实现对象权限的授予和回收：

#创建连接 [omm@localhost root]$ gsql -d postgres -r gsql ((openGauss 3.1.0 build 4e931f9a) compiled at 2022-09-29 14:40:01 commit 0 last mr release) Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. #创建测试数据 openGauss=# create database testdb; CREATE DATABASE openGauss=# \c testdb Non-SSL connection (SSL connection is recommended when requiring high-security) You are now connected to database "testdb" as user "omm". testdb=# create user test identified by 'test@123'; NOTICE: The encrypted password contains MD5 ciphertext, which is not secure. CREATE ROLE testdb=# create user user1 identified by 'test@123'; NOTICE: The encrypted password contains MD5 ciphertext, which is not secure. CREATE ROLE testdb=# alter database testdb owner to test; ALTER DATABASE testdb=# set search_path to test; SET testdb=# create table tbl1 (id int); CREATE TABLE testdb=# insert into tbl1 values(1),(2),(3); INSERT 0 3
#例1：将对表tbl1进行select的权限以及将select再赋权的权限授予用户user1, #赋权后用户user1有权对tbl执行select操作且user1有权限将select权限再赋予其他用户 [omm@home ~]$ gsql -d testdb -c "GRANT select ON TABLE test.tbl1 TO user1 WITH GRANT OPTION" GRANT [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select * from test.tbl1" ERROR: permission denied for schema test LINE 1: select * from test.tbl1 ^ DETAIL: N/A #如上因为user1没有test模式的usage权限，所以即便给他授权了模式下的表的select权限也访问不了 gsql -d testdb -c "GRANT usage ON schema test TO user1" [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO user1" GRANT [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select * from test.tbl1" id ---- 1 2 3 (3 rows)
#此时user1没有对表alter、drop的权限 [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "drop table test.tbl1" ERROR: permission denied for relation tbl1 DETAIL: N/A [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "alter table test.tbl1 add column name text" ERROR: permission denied for relation tbl1 DETAIL: N/A
#例2：将对表tbl1进行alter和drop的权限赋给用户user1 #赋权后用户user1有权对tbl1进行修改（ALTER）和删除（DROP）操作 [omm@home ~]$ gsql -d testdb -c "GRANT alter, drop ON TABLE test.tbl1 TO user1;" GRANT [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "alter table test.tbl1 add column name text" ALTER TABLE
#例3：撤销用户user1对表tbl进行select的权限 [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select * from test.tbl1" id | name ----+------ 1 | 2 | 3 | (3 rows)
[omm@home ~]$ gsql -d testdb -c "REVOKE select ON test.tbl1 FROM user1" REVOKE #撤销后用户user1对tbl进行select操作会报错： [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select * from test.tbl1" ERROR: permission denied for relation tbl1 DETAIL: N/A 本次项目的目的就在于区分对象权限的情况：

CREATE USER

• 通过CREATE USER创建的用户，默认具有LOGIN权限。

• 通过CREATE USER创建用户的同时，系统会在执行该命令的数据库中，为该用户创建一个同名的SCHEMA。

• 系统管理员在普通用户同名schema下创建的对象，所有者为schema的同名用户（非系统管理员）。

CREATE ROLE

• 角色是拥有数据库对象和权限的实体。在不同的环境中角色可以认为是一个用户，一个组或者兼顾两者。
• 在数据库中添加一个新角色，角色无登录权限。

• 创建角色的用户必须具备CREATE ROLE的权限或者是系统管理员。

schema

• Schema又称作模式。通过管理Schema，允许多个用户使用同一数据库而不相互干扰，可以将数据库对象组织成易于管理的逻辑组，同时便于将第三方应用添加到相应的Schema下而不引起冲突。

三权分立机制

伴随着数据库的发展以及所面向业务场景的扩展，对数据库权限分离以及权限管理的细粒度划化提出了更高的要求，为了满足多样化用户的业务安全要求，openGauss数据库针对权限模型进行了更细粒度的权限划分，使得用户可以更灵活地依据实际业务进行用户权限分配和管理，除了基本系统权限和对象权限的划分外，还有一些高阶的权限管理机制用来满足客户的业务诉求，比如三权分立机制。

openGauss安装完成后会得到一个具有最高权限的超级用户。数据库超级用户的高权限意味着该用户可以做任何系统管理操作和数据管理操作,甚至可以修改数据库对象,包括接下来将要介绍的审计日志信息。对于企业管理来说, 手握超级用户权限的管理人员可以在无人知晓的情况下改变数据行为,这带来的后果是不可想象的。

在上文提到，初始化用户不允许远程登录,仅可本地登录。那么,在组织行为上由IT 部门严格监控拥有该权限的员工在本地的操作行为，就可有效避免诸如修改表中数据等“监守自盗”行为的发生。为了实际管理需要，在数据库内部就需要其他的管理员用户来管理整个系统，如果将大部分的系统管理权限都交给某一个用户来执行，实际上也是不合适的，因为这等同于超级用户。

为了很好地解决权限高度集中的问题，在openGauss系统中引入三权分立角色模型，如图所示。三权分立角色模型最关键的三个角色为安全管理员、系统管理员和审计管理员。其中，安全管理员用于创建数据管理用户；系统管理员对创建的用户进行赋权；审计管理员则审计安全管理员、系统管理员、普通用户实际的操作行为。

通过三权分立角色模型实现权限的分派，且三个管理员角色独立行使权限，相互制约制衡。使得整个系统的权限不会因为权限集中而引入安全的风险。

事实上，产品使用过程中的安全是技术本身与组织管理双重保障的结果，在系统实现三权分立模型后，需要有三个对应的产品自然人分别握有对应的账户信息，以达到真正权限分离的目的。

三权分立是对系统权限管理机制的补充，核心思想是将管理数据库对象的权限、管理用户的权限和管理审计日志的权限分离，从而避免一个管理员拥有过度集中的权利带来的高风险。通过将GUC参数enableSeparationOfDuty设置为on来打开三权分立开关。

openGauss=# select name,setting,unit,context from pg_settings where name ~ 'enableSeparationOfDuty'; name | setting | unit | context ------------------------+---------+------+------------ enableSeparationOfDuty | off | | postmaster (1 row) 三权分立开关打开后，SYSADMIN的权限范围将缩小，不再包括允许创建用户/角色的权限，也不再包括允许查看、删除数据库审计日志的权限。SYSADMIN，CREATEROLE，AUDITADMIN三种系统权限的权限范围互相隔离，互不影响，而且一个用户仅能被赋予其中一个属性。 三权分立打开后的权限范围如下：

• 列级访问控制

在一些业务场景中，数据表中的某些列存储了重要的信息，需要对用户不可见，但其他列的数据又需要用户能够查看或操作，此时就需要针对数据表的特定列做访问控制，实现针对用户的列级别的访问控制。

#创建测试数据 gsql -d postgres -r create database testdb; \c testdb create user test identified by 'test@123'; create user user1 identified by 'test@123'; alter database testdb owner to test; set search_path to test; create table tbl (id int,name varchar(20)); insert into tbl values(1,'test1'),(2,'test2'),(3,'test3');
#例1：将对表tbl的第一列(id)进行select的权限和对表tbl的第二列(name)进行update的权限授予用户user1 #赋权后用户user1有权对tbl的第一列执行select操作和对第二列执行update操作 [omm@home ~]$ gsql -d testdb -c "GRANT select(id),update(name) ON TABLE test.tbl TO user1;" GRANT [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select id from test.tbl" ERROR: permission denied for schema test LINE 1: select id from test.tbl ^ DETAIL: N/A #如上因为user1没有test模式的usage权限，所以即便给他授权了模式下的表的select权限也访问不了 [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO user1" GRANT [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select id from test.tbl" id ---- 1 2 3 (3 rows) [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select name from test.tbl" ERROR: permission denied for relation tbl DETAIL: N/A
[omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "update test.tbl set name = 'haha' where id=3" UPDATE 1 [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "update test.tbl set id = 4 where id=3" ERROR: permission denied for relation tbl DETAIL: N/A #例2：撤销用户user1对表tbl的第一列id进行select的权限 #撤销后用户user1不再具有查看表tbl的第一列id数据的权限 [omm@home ~]$ gsql -d testdb -c "REVOKE select(id) ON test.tbl FROM user1" REVOKE [omm@home ~]$ gsql -d testdb -U user1 -W test@123 -c "select id from test.tbl" ERROR: permission denied for relation tbl DETAIL: N/A

• 行级访问控制

在实际业务中还存在另外一种场景，同一张数据表，只允许用户查看满足特定条件的行数据，此时就需要将访问控制精确到数据表的行级别，使得不同用户执行相同的SQL查询、更新或删除操作，读取到的结果是不同的。 用户可以在数据表上创建行级访问控制(row level security)策略，该策略是针对特定数据库用户、特定SQL操作生效的表达式。当数据库用户访问数据表时，满足策略条件的行对用户可见，不满足条件的行对用户不可见，从而实现针对用户的行级别的访问控制。 openGauss提供SQL语句CREATE/ALTER/DROP ROW LEVEL SECURITY进行行级访问权限策略的创建/修改/删除操作：

#创建测试数据 gsql -d postgres -r create database testdb; \c testdb create user test identified by 'test@123'; create user mary identified by 'test@123'; create user tom identified by 'test@123'; alter database testdb owner to test;
set search_path to test; #步骤1：创建信息表pat_info记录医院病人的个人信息： create table pat_info(patience varchar(20),doctor varchar(20),age int); insert into pat_info values('peter','mary',25),('bob','mary',56),('julie','tom',38)
#查询表数据 [omm@home ~]$ gsql -d testdb -U test -W test@123 -c "select * from test.pat_info" patience | doctor | age ----------+--------+----- peter | mary | 25 bob | mary | 56 julie | tom | 38 (3 rows)
#步骤2：创建行级访问控制策略，使得医生只能查看属于自己的病人信息： [omm@home ~]$ gsql -d testdb -c "CREATE ROW LEVEL SECURITY POLICY rls_select ON test.pat_info FOR select USING(doctor=current_user)" CREATE ROW LEVEL SECURITY POLICY
#步骤3：打开信息表pat_info上的行级访问控制开关 [omm@home ~]$ gsql -d testdb -c "ALTER TABLE test.pat_info ENABLE ROW LEVEL SECURITY;" ALTER TABLE
#步骤4：将信息表pat_info的查看权限赋予所有人 [omm@home ~]$ gsql -d testdb -c "grant select on table test.pat_info to public;" GRANT
#步骤5：Mary医生的查看结果： [omm@home ~]$ gsql -d testdb -U mary -W test@123 -c "select * from test.pat_info" ERROR: permission denied for schema test LINE 1: select * from test.pat_info ^ DETAIL: N/A [omm@home ~]$ [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO mary" GRANT [omm@home ~]$ gsql -d testdb -U mary -W test@123 -c "select * from test.pat_info" patience | doctor | age ----------+--------+----- peter | mary | 25 bob | mary | 56 (2 rows)
#Tom医生的查看结果： [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO tom" GRANT [omm@home ~]$ gsql -d testdb -U tom -W test@123 -c "select * from test.pat_info"

• 行级访问控制
  

在实际业务中还存在另外一种场景，同一张数据表，只允许用户查看满足特定条件的行数据，此时就需要将访问控制精确到数据表的行级别，使得不同用户执行相同的SQL查询、更新或删除操作，读取到的结果是不同的。

用户可以在数据表上创建行级访问控制(row level security)策略，该策略是针对特定数据库用户、特定SQL操作生效的表达式。当数据库用户访问数据表时，满足策略条件的行对用户可见，不满足条件的行对用户不可见，从而实现针对用户的行级别的访问控制。

openGauss提供SQL语句CREATE/ALTER/DROP ROW LEVEL SECURITY进行行级访问权限策略的创建/修改/删除操作：

#创建测试数据 gsql -d postgres -r create database testdb; \c testdb create user test identified by 'test@123'; create user mary identified by 'test@123'; create user tom identified by 'test@123'; alter database testdb owner to test;
set search_path to test; #步骤1：创建信息表pat_info记录医院病人的个人信息： create table pat_info(patience varchar(20),doctor varchar(20),age int); insert into pat_info values('peter','mary',25),('bob','mary',56),('julie','tom',38)
#查询表数据 [omm@home ~]$ gsql -d testdb -U test -W test@123 -c "select * from test.pat_info" patience | doctor | age ----------+--------+----- peter | mary | 25 bob | mary | 56 julie | tom | 38 (3 rows)
#步骤2：创建行级访问控制策略，使得医生只能查看属于自己的病人信息： [omm@home ~]$ gsql -d testdb -c "CREATE ROW LEVEL SECURITY POLICY rls_select ON test.pat_info FOR select USING(doctor=current_user)" CREATE ROW LEVEL SECURITY POLICY #步骤3：打开信息表pat_info上的行级访问控制开关 [omm@home ~]$ gsql -d testdb -c "ALTER TABLE test.pat_info ENABLE ROW LEVEL SECURITY;" ALTER TABLE #步骤4：将信息表pat_info的查看权限赋予所有人 [omm@home ~]$ gsql -d testdb -c "grant select on table test.pat_info to public;" GRANT #步骤5：Mary医生的查看结果： [omm@home ~]$ gsql -d testdb -U mary -W test@123 -c "select * from test.pat_info" ERROR: permission denied for schema test LINE 1: select * from test.pat_info ^ DETAIL: N/A [omm@home ~]$ [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO mary" GRANT [omm@home ~]$ gsql -d testdb -U mary -W test@123 -c "select * from test.pat_info" patience | doctor | age ----------+--------+----- peter | mary | 25 bob | mary | 56 (2 rows)
#Tom医生的查看结果： [omm@home ~]$ gsql -d testdb -c "GRANT usage ON schema test TO tom" GRANT [omm@home ~]$ gsql -d testdb -U tom -W test@123 -c "select * from test.pat_info"

权限规划示例

将测试用例全部移植完成，本次移植涉及7个测试文件、全部功能接口和搜索选项、近3000行代码，针对实机进行单元测试，发现其中的不符合预期的功能接口，针对性进行调试适配，确保功能可用。最后整理测试报告TESE.md文件，列明测试用例涉及的接口和实机测试结果。 

本示例以项目维度进行权限管理示例。

• DBA拥有open Gauss实例的高权限账号，名称是dbsuperuser。

• 举例业务项目名称是oaauth，OA系统，新建schema名称是oaauth、oaauth_1。

项目中新增的资源owner账号和角色Role规划如下：

新增业务账号时，根据不同需求，采用如下管理模式创建：

• oaauth_readwrite = oaauth_role_readwrite + login权限
• oaauth_readonly = oaauth_role_readonly + login权限

就是通过角色加登录权限设计为需要的新的账号。

配置步骤

1. 创建项目资源owner账号oaauth_owner和项目Role。 DBA使用dbsuperuser高权限账号执行如下操作。

--- oaauth_owner 是项目管理账号,此处密码仅为示例，请注意修改。 CREATE USER oaauth_owner WITH LOGIN PASSWORD 'asdfy181BASDfadasdbfas';
CREATE ROLE oaauth_role_readwrite; CREATE ROLE oaauth_role_readonly;
--- 设置: 对于oaauth_owner 创建的表，oaauth_role_readwrite 有 DQL（SELECT）、DML（UPDATE、INSERT、DELETE）权限。 ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT ALL ON TABLES TO oaauth_role_readwrite;
--- 设置: 对于oaauth_owner 创建的SEQUENCES，oaauth_role_readwrite 有 DQL（SELECT）、DML（UPDATE、INSERT、DELETE）权限。 ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT ALL ON SEQUENCES TO oaauth_role_readwrite;
--- 设置: 对于 oaauth_owner 创建的表， oaauth_role_readonly 只有 DQL（SELECT）权限。 ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT SELECT ON TABLES TO oaauth_role_readonly; 2. 创建oaauth_readwrite、oaauth_readonly业务账号。  DBA使用dbsuperuser高权限账号执行如下操作。
--- oaauth_readwrite只有 DQL（SELECT）、DML（UPDATE、INSERT、DELETE）权限。 CREATE USER oaauth_readwrite WITH LOGIN PASSWORD 'dfandfnapSDhf23hbEfabf'; GRANT oaauth_role_readwrite TO oaauth_readwrite;
--- oaauth_readonly只有 DQL（SELECT）权限。 CREATE USER oaauth_readonly WITH LOGIN PASSWORD 'F89h912badSHfadsd01zlk'; GRANT oaauth_role_readonly TO oaauth_readonly;

3. 创建schema oaauth，并授权给项目Role。

DBA使用dbsuperuser高权限账号执行如下操作。

--- schema oaauth的owner是 oaauth_owner账号 CREATE SCHEMA oaauth AUTHORIZATION oaauth_owner;
--- 授权ROLE相关SCHEMA访问权限。 GRANT USAGE ON SCHEMA oaauth TO oaauth_role_readwrite; GRANT USAGE ON SCHEMA oaauth TO oaauth_role_readonly;

说明：

oaauth_readwrite和oaauth_readonly自动继承了相关Role的权限变更，不需要再额外操作。

应用场景示例

场景1：使用oaauth_owner账号：对schema oaauth中的表进行DDL（CREATE、DROP、ALTER）操作

CREATE TABLE oaauth.test(id bigserial primary key, name text); CREATE INDEX idx_test_name on oaauth.test(name); 场景2：使用 oaauth_readwrite/oaauth_readonly 账号进行业务开发 业务开发遵循最小权限原则，尽量使用oaauth_readonly账号，需要DML操作的地方才使用oaauth_readwrite账号。这样也方便在业务层做读写分离。

说明：

• 业务层做读写分离，避免了自动读写分离中间件proxy带来的额外成本和性能损耗。

• 即使目前还没有使用只读实例，也建议区分 readonly客户端、readwrite客户端，为使用只读实例做准备。readonly客户端建议使用readonly账号，最小权限原则，规避权限误用。

  – readonly客户端，使用readonly账号，设置JDBC URL：只读实例1地址,只读实例2地址,读写实例地址。

  – readwrite客户端，使用readwrite账号，设置JDBC URL：读写实例地址。

• 使用oaauth_readwrite账号，对schema oaauth中的表进行DQL（SELECT）、DML（UPDATE、INSERT、DELETE）操作：

• 
  

INSERT INTO oaauth.test (name) VALUES('name0'),('name1'); SELECT id,name FROM oaauth.test LIMIT 1;
--- oaauth_readwrite没有 DDL（CREATE、DROP、ALTER）权限 CREATE TABLE oaauth.test2(id int); ERROR: permission denied for schema oaauth LINE 1: create table oaauth.test2(id int);
DROP TABLE oaauth.test; ERROR: must be owner of table test
ALTER TABLE oaauth.test ADD id2 int; ERROR: must be owner of table test
CREATE INDEX idx_test_name on oaauth.test(name); ERROR: must be owner of table test

• 使用oaauth_readonly账号，对schema oaauth中的表进行DQL（SELECT）操作：

• 
  

INSERT INTO oaauth.test (name) VALUES('name0'),('name1'); ERROR: permission denied for table test
SELECT id,name FROM oaauth.test LIMIT 1; id | name ----+------- 1 | name0 (1 row)

场景3：不同项目交叉授权

如果有另外1个项目employee，需求为账号employee_readwrite增加oaauth项目的表只读权限。DBA使用dbsuperuser高权限账号做如下操作：
--- 给账号 employee_readwrite 加上 oaauth_role_readonly 权限集合。 GRANT oaauth_role_readonly TO employee_readwrite; 场景4：项目新增 schema oaauth_2，并授权给项目Role oaauth_readwrite、oaauth_readonly、employee_readwrite账号自动继承了相关Role的权限变更，不需要再额外操作。DBA使用dbsuperuser 高权限账号做如下操作：
CREATE SCHEMA oaauth_1 AUTHORIZATION oaauth_owner;
--- 授权ROLE相关SCHEMA访问权限。 --- CREATE 使得 oaauth_role_admin 对schema oaauth_1中的表有 DDL（CREATE、DROP、ALTER）权限。 GRANT USAGE ON SCHEMA oaauth_1 TO oaauth_role_readwrite; GRANT USAGE ON SCHEMA oaauth_1 TO oaauth_role_readonly; 账号权限查询

通过本文介绍的账号权限管理模型创建的账号，可以通过如下方式查询具体权限信息。

• 使用PostgreSQL客户端命令行终端连接RDS PostgreSQL数据库，具体请参见连接PostgreSQL实例 。然后使用\du命令查看：

从上述查询结果示例中可以看出：employee_readwrite账号的Member of列中，内容为oaauth_role_readonly,employee_role_readwrite，因此，此账号对employee项目表具有DQL和DML权限，对oaauth项目表具有DQL权限。

• 使用SQL查询：

SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcreatedb, r.rolcanlogin, r.rolconnlimit, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof , r.rolreplication , r.rolbypassrls FROM pg_catalog.pg_roles r WHERE r.rolname !~ '^pg_' ORDER BY 1;

用户权限查询实例

查询用户：\du

查询用户opengauss的数据库的权限：

opengauss=# select a.datname,b.rolname,string_agg(a.pri_t,',') from (select datname,(aclexplode(COALESCE(datacl, acldefault('d'::"char",datdba)))).grantee as grantee,(aclexplode(COALESCE(datacl, acldefault('d'::"char", datdba)))).privilege_type as pri_t from pg_database where datname not like 'template%') a,pg_roles b where (a.grantee=b.oid or a.grantee=0) and b.rolname='opengauss' group by a.datname,b.rolname;
datname | rolname | string_agg ---------------+-----------+-------------------------------------------- testdb | opengauss | TEMPORARY,CONNECT db_department | opengauss | TEMPORARY,CONNECT postgres | opengauss | TEMPORARY,CONNECT opengauss | opengauss | TEMPORARY,CONNECT,CREATE,TEMPORARY,CONNECT (4 rows)

显示用户opengauss对于opengauss数据库具有TEMPORARY,CONNECT,CREATE,TEMPORARY,CONNECT等权限

根据用户名查询table 权限，可以通过视图information_schema.table_privileges来查看，为了方便展示，sql如下

opengauss=# select table_name,table_schema,grantee,string_agg(privilege_type,',') from information_schema.table_privileges where grantee='opengauss' group by table_name,table_schema,grantee; 如图所示，omm对于各个表都具有权限。

# 开源之夏个人随访 --项目经历-- OSPP： 和大家介绍一下自己吧。 陈贤文： 大家好！我是来自华科的陈贤文同学，专业是机械工程，目前在国家数控中心从事数控系统算法优化与功能开发，对软件开发和开源很感兴趣，喜欢用程序化的方式解决重复性问题。 OSPP：最初是怎样接触到开源的？介绍一下自己的开源项目经历？ 陈贤文：最早接触开源是在高中的时候，班上组织活动需要使用录屏工具，上网了解到了OBS Studio，这款开源软件十分的实用，给我留下了深刻的印象。主要的项目经历一个是使用Java开发了一款商家外卖后端管理平台，完整的学习了项目开发流程，锻炼了基本的开发能力，还有就是自身在从事的数控系统的开发项目，主要是对新型加工代码进行识别加工和规划。 OSPP：之前掌握的技术栈和项目经验对你此次开源之夏项目开发有什么帮助吗？ 陈贤文：有很大的帮助，本次开发主要是对openGauss的权限扫描和安全策略设计，通过学习，我掌握了数据库访问控制的操作，会使用SpringBoot来搭建开发的框架。 OSPP：以你所在的高校为例，你觉得当前高校学生参与开源的氛围怎么样？高校学生参与开源的机会多吗？ 陈贤文：当前高校学生参与开源的热情很高，我们实验室就有很多人报名开源之夏，但是我们高校学生参与开源的机会确实相对来说比较少，技术性的开源工作对同学来说门槛还是有一定的高。 --参与开源社区-- OSPP：参与开源之夏之前是否参与过开源社区？参与开源之夏的过程中你对社区的认识有什么变化吗？ 陈贤文：这是我第一次加入到开源社区中来，我之前对开源软件和开源社区的概念和运作方式有一些了解，但并没有实际参与过其中的活动或贡献。参与开源之夏让我明白了在开源社区中贡献的重要性，无论是提交代码、修复漏洞、编写文档还是提供技术支持。每个小的贡献都可以对整个社区产生积极的影响，并推动项目的进步。 OSPP：你认为团队协作能力在开源中是如何体现的？ 陈贤文：比如分工合作，协同开发，对一个功能一起做贡献，还可以社区互动，分享经验，提供帮助等。 OSPP：在开发过程中，有什么印象深刻的问题或经历吗？社区和导师为你提供了怎样的帮助？ 陈贤文 ： 深刻的点在刚开始接触openGauss，连接的时候会各种报错，自己研究了之后，寻求社区的帮助，大家一起交流，我在过程中也结识了很多伙伴，导师给我指导了大概的思路和方法，对我的学习指出了方向。 OSPP： 是否会持续参与开源社区呢？为什么？ 陈贤文 ：我还会继续参与开源社区，为开源做出自己的一份力，受益于开源，回馈于开源，提升自我，展现自我。

--寄语--

OSPP： 对想要参与以及还未参与开源的同学鼓励一下吧！ 陈贤文： 开源项目就在那里，总有一些新的需求和方向可以为之贡献自己的力量，当我们就有了一定的技术能力和知识储备，了解和掌握开源工具、语言和框架了之后，就一起来加入开源社区吧！找到合适的开源项目之后，勇敢和导师与社区开发者交流，参与进来，一起分享自己的知识和经验，帮助他人解决问题，一起学习与成长！

这篇关于项目经验分享｜openGauss 陈贤文：受益于开源，回馈于开源的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---