正文
Oracle数据库权限学习--表或者是视图不存在
摘要
本文写于: 12.10 01:00 巴西踢的太烂了
帮同事看一下补丁执行报错的问题.
问题原因很简单. user_all_table能够后去本用户权限
下所有架构表空间下面的表.
如果A架构下没有一个表, 但是同一个数据库instanceID下面有一个B架构下有这个表
并且A用户具有 dba 权限, 那么在A用户下查询是否存在这个表, 会查询出是来
如果再去再A用户下处理这张表, 就会报错.
select count(1) from user_all_Tables where Table_Name = 'TBTMPxxx'
问题原因以及思考
其实问题非常简单, 最简单的处理方法是
不应该在执行的SQL内部内使用 user_all_tables的语法.
因为这个会放大用户查询的范围, 这个问题其实十三年前就开始说了,
但是研发总是一直很自信的用.
这个问题屡禁不止.
我也感觉比较奇怪,为啥我这边没发现, 怀疑是不是用户权限有关系.
其实简单一查询的确能够发现存在较多的风险.
问题深入发掘
12.10 01:10 其实发现自己已经把问题原因弄错了..
但是这个文章还是想继续写一下.
第一步: 分析Oracle用户的权限:
# 查看用户具有的角色
select * from dba_role_privs where grantee ='CLOUD2099';
# 查看用户具有的权限
select * from dba_sys_privs where grantee ='CLOUD2099';
# 注意之前为了简单, 备份恢复的测试使用了dba的权限
# 这样会导致出现上一节分析的出现的问题原因.
用户一般具备如下权限就可以了:
CREATE TABLESPACE
CREATE ANY TABLE
ALTER ROLLBACK SEGMENT
CREATE RULE
CREATE ANY SEQUENCE
CREATE SESSION
UNLIMITED TABLESPACE
CREATE ANY VIEW
DROP TABLESPACE
CREATE ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT
CREATE TRIGGER
生产环境非常不建议 有DBA权限
其他不应该有的权限
今天晚上做了一个实验, 发现如果具备:
EXP_FULL_DATABASE
角色的用户, 也会出现一定的权限扩大化.
当然风险较小(极难利用)
具备这个角色的用户不仅仅可以备份恢复自己的数据库
还可以将整个数据库实例下所有的数据库实例进行备份恢复
可能会存在权限扩大化的风险.
如果是等保或者是高安全性的场景, 建议也不要赋予这个权限.
其他数据库的举一反三
1. 生产必须严格杜绝DBA用户权限的情况. 任何数据库都不行.
2. 备份恢复也建议最小化权限原则,避免权限失真.
3. 研发必须严格遵守属地属主原则,不要任意过大表或者是视图范围.
4. 业务表名一定要有业务含义,不要加太多TMP标识..
Oracle数据库权限的简单学习与扩展
12.10 01:25 巴西1:0 克罗地亚
1、查看所有用户
select * from dba_user;
select * from all_users;
select * from user_users;
2、查看用户系统权限
select * from dba_sys_privs;
select * from all_sys_privs;
select * from user_sys_privs;
3、查看用户对象权限
select * from dba_tab_privs;
select * from all_tab_privs;
select * from user_tab_privs;
4、查看所有角色
select * from dba_roles;
5、查看用户所拥有的角色
select * from dba_role_privs;
select * from user_role_privs;
6、查看当前用户的缺省表空间
select username,default_tablespace from user_users;
7、查看某个角色的具体权限
如 grant connect,resource,create session,create view to TEST;
8、查看RESOURCE具有那些权限
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE='RESOURCE
Study From https://www.cnblogs.com/huazhixu/p/15788803.html
