商城网站建设实例需求,wordpress 内网穿透,网站推广的效果好,万网域名解析面板开源之夏
项目经验分享 2023 #08 # 关于 openGauss 社区 openGauss是一款开源关系型数据库管理系统#xff0c;采用木兰宽松许可证v2发行。openGauss内核深度融合华为在数据库领域多年的经验#xff0c;结合企业级场景需求#xff0c;持续构建竞争力特性。同时openGauss也是…开源之夏
项目经验分享 2023 #08 #nbsp;关于 openGaussnbsp;社区 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 openGauss2021;
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实现对象权限的授予和回收 #创建连接
[ommlocalhost 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 test123;
NOTICE: The encrypted password contains MD5 ciphertext, which is not secure.
CREATE ROLE
testdb# create user user1 identified by test123;
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权限再赋予其他用户
[ommhome ~]$ gsql -d testdb -c GRANT select ON TABLE test.tbl1 TO user1 WITH GRANT OPTION
GRANT
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -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
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO user1
GRANT
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c select * from test.tbl1 id
---- 1 2 3
(3 rows) #此时user1没有对表alter、drop的权限
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c drop table test.tbl1
ERROR: permission denied for relation tbl1
DETAIL: N/A
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -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操作
[ommhome ~]$ gsql -d testdb -c GRANT alter, drop ON TABLE test.tbl1 TO user1;
GRANT
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c alter table test.tbl1 add column name text
ALTER TABLE #例3撤销用户user1对表tbl进行select的权限
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c select * from test.tbl1 id | name
---------- 1 | 2 | 3 |
(3 rows) [ommhome ~]$ gsql -d testdb -c REVOKE select ON test.tbl1 FROM user1
REVOKE
#撤销后用户user1对tbl进行select操作会报错
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -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的权限范围将缩小不再包括允许创建用户/角色的权限也不再包括允许查看、删除数据库审计日志的权限。SYSADMINCREATEROLEAUDITADMIN三种系统权限的权限范围互相隔离互不影响而且一个用户仅能被赋予其中一个属性。
三权分立打开后的权限范围如下 列级访问控制
在一些业务场景中数据表中的某些列存储了重要的信息需要对用户不可见但其他列的数据又需要用户能够查看或操作此时就需要针对数据表的特定列做访问控制实现针对用户的列级别的访问控制。
#创建测试数据
gsql -d postgres -r
create database testdb;
\c testdb
create user test identified by test123;
create user user1 identified by test123;
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操作
[ommhome ~]$ gsql -d testdb -c GRANT select(id),update(name) ON TABLE test.tbl TO user1;
GRANT
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -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权限也访问不了
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO user1
GRANT
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c select id from test.tbl id
---- 1 2 3
(3 rows)
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c select name from test.tbl
ERROR: permission denied for relation tbl
DETAIL: N/A [ommhome ~]$ gsql -d testdb -U user1 -W test123 -c update test.tbl set name haha where id3
UPDATE 1
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -c update test.tbl set id 4 where id3
ERROR: permission denied for relation tbl
DETAIL: N/A
#例2撤销用户user1对表tbl的第一列id进行select的权限
#撤销后用户user1不再具有查看表tbl的第一列id数据的权限
[ommhome ~]$ gsql -d testdb -c REVOKE select(id) ON test.tbl FROM user1
REVOKE
[ommhome ~]$ gsql -d testdb -U user1 -W test123 -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 test123;
create user mary identified by test123;
create user tom identified by test123;
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) #查询表数据
[ommhome ~]$ gsql -d testdb -U test -W test123 -c select * from test.pat_info patience | doctor | age
----------------------- peter | mary | 25 bob | mary | 56 julie | tom | 38
(3 rows) #步骤2创建行级访问控制策略使得医生只能查看属于自己的病人信息
[ommhome ~]$ gsql -d testdb -c CREATE ROW LEVEL SECURITY POLICY rls_select ON test.pat_info FOR select USING(doctorcurrent_user)
CREATE ROW LEVEL SECURITY POLICY #步骤3打开信息表pat_info上的行级访问控制开关
[ommhome ~]$ gsql -d testdb -c ALTER TABLE test.pat_info ENABLE ROW LEVEL SECURITY;
ALTER TABLE #步骤4将信息表pat_info的查看权限赋予所有人
[ommhome ~]$ gsql -d testdb -c grant select on table test.pat_info to public;
GRANT #步骤5Mary医生的查看结果
[ommhome ~]$ gsql -d testdb -U mary -W test123 -c select * from test.pat_info
ERROR: permission denied for schema test
LINE 1: select * from test.pat_info ^
DETAIL: N/A
[ommhome ~]$
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO mary
GRANT
[ommhome ~]$ gsql -d testdb -U mary -W test123 -c select * from test.pat_info patience | doctor | age
----------------------- peter | mary | 25 bob | mary | 56
(2 rows) #Tom医生的查看结果
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO tom
GRANT
[ommhome ~]$ gsql -d testdb -U tom -W test123 -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 test123;
create user mary identified by test123;
create user tom identified by test123;
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) #查询表数据
[ommhome ~]$ gsql -d testdb -U test -W test123 -c select * from test.pat_info patience | doctor | age
----------------------- peter | mary | 25 bob | mary | 56 julie | tom | 38
(3 rows) #步骤2创建行级访问控制策略使得医生只能查看属于自己的病人信息
[ommhome ~]$ gsql -d testdb -c CREATE ROW LEVEL SECURITY POLICY rls_select ON test.pat_info FOR select USING(doctorcurrent_user)
CREATE ROW LEVEL SECURITY POLICY
#步骤3打开信息表pat_info上的行级访问控制开关
[ommhome ~]$ gsql -d testdb -c ALTER TABLE test.pat_info ENABLE ROW LEVEL SECURITY;
ALTER TABLE
#步骤4将信息表pat_info的查看权限赋予所有人
[ommhome ~]$ gsql -d testdb -c grant select on table test.pat_info to public;
GRANT
#步骤5Mary医生的查看结果
[ommhome ~]$ gsql -d testdb -U mary -W test123 -c select * from test.pat_info
ERROR: permission denied for schema test
LINE 1: select * from test.pat_info ^
DETAIL: N/A
[ommhome ~]$
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO mary
GRANT
[ommhome ~]$ gsql -d testdb -U mary -W test123 -c select * from test.pat_info patience | doctor | age
----------------------- peter | mary | 25 bob | mary | 56
(2 rows) #Tom医生的查看结果
[ommhome ~]$ gsql -d testdb -c GRANT usage ON schema test TO tom
GRANT
[ommhome ~]$ gsql -d testdb -U tom -W test123 -c select * from test.pat_info
权限规划示例
将测试用例全部移植完成本次移植涉及7个测试文件、全部功能接口和搜索选项、近3000行代码针对实机进行单元测试发现其中的不符合预期的功能接口针对性进行调试适配确保功能可用。最后整理测试报告TESE.md文件列明测试用例涉及的接口和实机测试结果。nbsp;
本示例以项目维度进行权限管理示例。
DBA拥有open Gauss实例的高权限账号名称是dbsuperuser。举例业务项目名称是oaauthOA系统新建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 有 DQLSELECT、DMLUPDATE、INSERT、DELETE权限。
ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT ALL ON TABLES TO oaauth_role_readwrite; --- 设置: 对于oaauth_owner 创建的SEQUENCESoaauth_role_readwrite 有 DQLSELECT、DMLUPDATE、INSERT、DELETE权限。
ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT ALL ON SEQUENCES TO oaauth_role_readwrite; --- 设置: 对于 oaauth_owner 创建的表 oaauth_role_readonly 只有 DQLSELECT权限。
ALTER DEFAULT PRIVILEGES FOR ROLE oaauth_owner GRANT SELECT ON TABLES TO oaauth_role_readonly;
2. 创建oaauth_readwrite、oaauth_readonly业务账号。
nbsp;DBA使用dbsuperuser高权限账号执行如下操作。
--- oaauth_readwrite只有 DQLSELECT、DMLUPDATE、INSERT、DELETE权限。
CREATE USER oaauth_readwrite WITH LOGIN PASSWORD dfandfnapSDhf23hbEfabf;
GRANT oaauth_role_readwrite TO oaauth_readwrite; --- oaauth_readonly只有 DQLSELECT权限。
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中的表进行DDLCREATE、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中的表进行DQLSELECT、DMLUPDATE、INSERT、DELETE操作
INSERT INTO oaauth.test (name) VALUES(name0),(name1);
SELECT id,name FROM oaauth.test LIMIT 1; --- oaauth_readwrite没有 DDLCREATE、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中的表进行DQLSELECT操作
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中的表有 DDLCREATE、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实例nbsp;。然后使用\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.granteeb.oid or a.grantee0) and b.rolnameopengauss 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 granteeopengauss group by table_name,table_schema,grantee;
如图所示omm对于各个表都具有权限。 # 开源之夏个人随访
--项目经历--
OSPP
和大家介绍一下自己吧。
陈贤文
大家好我是来自华科的陈贤文同学专业是机械工程目前在国家数控中心从事数控系统算法优化与功能开发对软件开发和开源很感兴趣喜欢用程序化的方式解决重复性问题。
OSPP最初是怎样接触到开源的介绍一下自己的开源项目经历
陈贤文最早接触开源是在高中的时候班上组织活动需要使用录屏工具上网了解到了OBS Studio这款开源软件十分的实用给我留下了深刻的印象。主要的项目经历一个是使用Java开发了一款商家外卖后端管理平台完整的学习了项目开发流程锻炼了基本的开发能力还有就是自身在从事的数控系统的开发项目主要是对新型加工代码进行识别加工和规划。
OSPP之前掌握的技术栈和项目经验对你此次开源之夏项目开发有什么帮助吗
陈贤文有很大的帮助本次开发主要是对openGauss的权限扫描和安全策略设计通过学习我掌握了数据库访问控制的操作会使用SpringBoot来搭建开发的框架。
OSPP以你所在的高校为例你觉得当前高校学生参与开源的氛围怎么样高校学生参与开源的机会多吗
陈贤文当前高校学生参与开源的热情很高我们实验室就有很多人报名开源之夏但是我们高校学生参与开源的机会确实相对来说比较少技术性的开源工作对同学来说门槛还是有一定的高。
--参与开源社区--
OSPP参与开源之夏之前是否参与过开源社区参与开源之夏的过程中你对社区的认识有什么变化吗
陈贤文这是我第一次加入到开源社区中来我之前对开源软件和开源社区的概念和运作方式有一些了解但并没有实际参与过其中的活动或贡献。参与开源之夏让我明白了在开源社区中贡献的重要性无论是提交代码、修复漏洞、编写文档还是提供技术支持。每个小的贡献都可以对整个社区产生积极的影响并推动项目的进步。
OSPP你认为团队协作能力在开源中是如何体现的
陈贤文比如分工合作协同开发对一个功能一起做贡献还可以社区互动分享经验提供帮助等。 OSPP在开发过程中有什么印象深刻的问题或经历吗社区和导师为你提供了怎样的帮助
陈贤文 深刻的点在刚开始接触openGauss连接的时候会各种报错自己研究了之后寻求社区的帮助大家一起交流我在过程中也结识了很多伙伴导师给我指导了大概的思路和方法对我的学习指出了方向。
OSPP
是否会持续参与开源社区呢为什么
陈贤文
我还会继续参与开源社区为开源做出自己的一份力受益于开源回馈于开源提升自我展现自我。
--寄语--
OSPP
对想要参与以及还未参与开源的同学鼓励一下吧
陈贤文
开源项目就在那里总有一些新的需求和方向可以为之贡献自己的力量当我们就有了一定的技术能力和知识储备了解和掌握开源工具、语言和框架了之后就一起来加入开源社区吧找到合适的开源项目之后勇敢和导师与社区开发者交流参与进来一起分享自己的知识和经验帮助他人解决问题一起学习与成长
