数据库中用户删除不掉总是报错,依赖如何处理干净?
摘要:本文主要介绍如何进行用户的各种依赖识别与清理,并简单介绍下推荐的权限管理方式。
本文分享自华为云社区《GaussDB(DWS) 用户删除不掉时候总是报错,依赖如何处理干净?》,作者:Malick 。
数据库的使用中,有时会遇到某些用户离职,或者角色变更时,要对其账号进行销户,权限进行回收等操作。此时如果各种对象的权限比较复杂,依赖较多,是很难顺利直接清理掉该用户的。
本文主要介绍如何进行用户的各种依赖识别与清理,并简单介绍下推荐的权限管理方式。
postgres类数据库经常碰到的问题 – role “test1” cannot be dropped because some objects depend on it
如下图所示,要删除用户test1时,出现如下提示:
testdb=# drop user test1; ERROR: role "test1" cannot be dropped because some objects depend on it DETAIL: owner of database testdb 3 objects in database postgres
ERROR的提示信息说明:
- 当前用户时testdb这个数据库的owner
- 有3个依赖的对象在postgres数据库中
OK,那么我们就按照提示信息来一次处理
首先,当前用户是一个数据库的owner,那么有以下两种处理办法
方法一、将数据库owner转移给其他用户,例如如下转移给grantor用户
testdb=# alter database testdb owner to grantor; ALTER DATABASE testdb=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+-----------+----------+-------------+-------------+------------------------- testdb | grantor | UTF8 | en_US.UTF-8 | en_US.UTF-8 | (4 rows) -- 可以看到删除后,不会再报owner database的信息 testdb=# drop user test1; ERROR: role "test1" cannot be dropped because some objects depend on it DETAIL: 3 objects in database postgres
方法二、如果不需要该库,也可以直接将其删除
PS:对于非数据库的对象:表或者schema等,可以使用如下方法将其全部转移给其他用户
-- owner转移 testdb=# REASSIGN OWNED BY test1 TO grantor; REASSIGN OWNED -- 清理owner是test1的对象,慎用,会将用户同名的schema也一同清理掉。 testdb=# drop owned by test1; DROP OWNED
接下来,我们owner的提示信息已经处理完了,处理下一步提示:3 objects in database postgres
这个意思是,在postgres里面有3个对象有依赖该用户。由于库内系统表的依赖,在其他数据库中不会打印出详细的依赖对象信息,那么在postgres库下去执行drop user的时候,会打印出具体的信息。
连接到postgres库执行如下:
postgres=# drop user test1; ERROR: role "test1" cannot be dropped because some objects depend on it DETAIL: privileges for table pg_class privileges for schema grantor
这里就可以看到,有两个依赖项:
- privileges for table pg_class:pg_class上test1用户的权限
- schema grator上test1用户的权限
那么,我们就可以直接看一下这两个对象对应的权限,去除即可。
postgres=# select relname,relacl from pg_class where relname = 'pg_class'; relname | relacl ----------+---------------------------------- pg_class | {=r/superuser,test1=r/superuser} (1 row) postgres=# select nspname,nspacl from pg_namespace where nspname = 'grantor'; nspname | nspacl ---------+--------------------------------------------------------- grantor | {grantor=UC/grantor,grantor=LP/grantor,test1=U/grantor} (1 row) postgres=# revoke select on table pg_class from test1; REVOKE postgres=# revoke usage on schema grantor from test1; REVOKE postgres=# drop user test1; DROP USER
此时再进行用户删除,就没有其他依赖了。
postgres=# drop user test1; DROP USER
PS:如果不知道具体对象还删不掉的时候,我们怎么操作呢,此处构造一个案例作为演示,新建用户test2,并赋予其grantor的select权限,此时无法drop
testdb2=# drop user test2; ERROR: role "test2" cannot be dropped because some objects depend on it DETAIL: 2 objects in database postgres
用户的依赖内部实际储存,为pg_shdepend系统表,里面记录了各个有依赖的对象的oid及其依赖关系。首先我们获取到用户的oid,再去系统表中找对应的依赖记录。
testdb2=# select oid ,rolname from pg_roles where rolname = 'test2'; oid | rolname ------------+--------- 2147484573 | test2 (1 row) postgres=# select * from pg_shdepend where refobjid = 2147484573; dbid | classid | objid | objsubid | refclassid | refobjid | deptype | objfile -------+---------+------------+----------+------------+------------+---------+--------- 16073 | 2615 | 2147484575 | 0 | 1260 | 2147484573 | o | 16073 | 2615 | 2147484025 | 0 | 1260 | 2147484573 | a | (2 rows) 这里由于dependType不同,因此有两条记录,一个代表权限依赖(a),一个代表自身是一个对象的owner。
我们获取到classid之后,这个代表依赖当前用户的对象的记录表的id,那么我们去pg_class表中找到这个依赖即可:
postgres=# select relname,relacl from pg_class where oid = 2615; relname | relacl --------------+---------------- pg_namespace | {=r/d00467397} (1 row)
OK,通过看到记录表是pg_namespace,那么就可以确认依赖用户的是一个schema。这里再到pg_namespace中,查上面获取到的objid,就知道了具体的对象
postgres=# select nspname,nspacl from pg_namespace where oid in (2147484575,2147484025); nspname | nspacl ---------+--------------------------------------------------------- test2 | grantor | {grantor=UC/grantor,grantor=LP/grantor,test2=U/grantor} (2 rows)
这里看到有两个schema,一个是用户同名的schema,一个是刚才赋权的grantor,赋权的处理掉之后,用户即可删除。
postgres=# revoke usage on schema grantor from test2; REVOKE postgres=# drop user test2; DROP USER

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Databend v1.2 版本发布!Data + AI
各位社区小伙伴们,Databend 于 2023 年 6 月 29 日迎来了 v1.2.0 版本的正式发布!相较于 v1.1.0 版本,开发者们一共新增了 600 次 commit,涉及 3083 个文件变更,约 17 万 行代码修改。感谢各位社区伙伴的参与,以及每一个让 Databend 变得更好的你! 在 v1.2.0 版本中,Databend 新增了 BITMAP 数据类型 、 使用列号直接查询 CSV/TSV/NDJSON 文件 、AI Functions 等特性,设计并实现全新哈希表 大幅提升 Join 的性能。这个版本的发布使得 Databend 更接近实现 LakeHouse 的愿景,能够直接读取和分析储存在对象存储上的 CSV/TSV/NDJSON/Parquet 等格式文件,你也可以在 Databend 内部对这些文件进行 ETL 操作,从而做一些更高性能的 OLAP 分析。 同时,Databend 也设计并实现了 计算列 、VACUUM TABLE 和 Serverless Background Service 等企业级特性,感兴趣的小伙伴可以联系 Databend...
- 下一篇
CXYGZL - 前后端全部开源的工作流 V2.0.2 版本发布
CXYGZL 介绍 现在开源的工作流引擎,基本都是以 BPMN.js 为基础的,导致使用门槛过高,非专业人员无法驾驭。本工作流借鉴钉钉 / 飞书的方式,以低代码方式降低用户使用门槛,即使是普通企业用户也可以几分钟内就能搭建自己的工作流引擎。 体验地址:https://pro.cxygzl.comCXYGZL 文档地址:https://www.cxygzl.comCXYGZL V2.0.2 版本介绍 ✨紧急修复了一些bug和添加了一些新功能,详细如下: 🏆 I7GLCU:添加表单组件-明细表 🏆 I7GECI:添加文本描述表单组件 🏆 I7GCIT:审批人支持角色 🏆 I7G8IF:添加并行分支 🏆 I7G8I2:添加表单组件:日期时间组件支持 🏆 I7G7Q4:流程组列表显示发起人范围 🏆 I7G7NU:表单组件库分组显示,流程基础信息的说明改成非必填 🏆 I7G78S:默认流程发起人是当前登录用户 🏆 I7G77S:只有发起人节点禁止保存流程 🏆 I7G77P:没有表单禁止发布流程 🎯 I7GUXL:表单拖拽组件之后会影响到原始表单 🎯 I7GG40:审批人执...
相关文章
文章评论
共有0条评论来说两句吧...