Si el usuario no se puede eliminar de la base de datos, siempre se informará un error ¿Cómo limpiar las dependencias?

Resumen: Este artículo presenta principalmente cómo identificar y limpiar varias dependencias de usuario, y presenta brevemente el método de administración de permisos recomendado.

Este artículo se comparte desde Huawei Cloud Community " Los usuarios de GaussDB (DWS) siempre informan errores cuando no se pueden eliminar. ¿Cómo limpiar las dependencias?" ", de Malik.

En el uso de la base de datos, en ocasiones cuando algunos usuarios dejan sus trabajos o cambian sus roles, es necesario cancelar sus cuentas y recuperar sus permisos. En este momento, si los permisos de varios objetos son más complicados y dependen más, es difícil limpiar al usuario sin problemas y directamente.

Este artículo presenta principalmente cómo identificar y limpiar varias dependencias de usuario y presenta brevemente el método de administración de permisos recomendado.

Problemas comunes que encuentran las bases de datos de Postgres: el rol "test1" no se puede descartar porque algunos objetos dependen de él.

Como se muestra en la figura a continuación, cuando se debe eliminar el usuario test1, aparece el siguiente mensaje:

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

Descripción del mensaje de aviso de ERROR:

  • El usuario actual es el propietario de la base de datos testdb
  • Hay 3 objetos dependientes en la base de datos de postgres

OK, entonces lo trataremos una vez de acuerdo con la información del sistema

En primer lugar, el usuario actual es el propietario de una base de datos, por lo que hay dos formas de manejarlo.

Método 1. Transfiera el propietario de la base de datos a otro usuario, por ejemplo, al usuario otorgante de la siguiente manera

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

Método 2. Si no necesita la biblioteca, también puede eliminarla directamente

PD: para objetos que no son de base de datos: tablas o esquemas, etc., puede usar el siguiente método para transferirlos todos a otros usuarios

-- owner转移
testdb=#  REASSIGN OWNED BY test1 TO grantor;
REASSIGN OWNED
-- 清理owner是test1的对象,慎用,会将用户同名的schema也一同清理掉。
testdb=# drop owned by test1;
DROP OWNED

A continuación, se procesó la información de solicitud de nuestro propietario y se indicó el siguiente paso: 3 objetos en la base de datos postgres

Esto significa que hay 3 objetos en postgres que dependen de este usuario. Debido a la dependencia de la tabla del sistema en la biblioteca, la información detallada del objeto dependiente no se imprimirá en otras bases de datos, por lo que cuando se ejecute el usuario de eliminación en la biblioteca de postgres, se imprimirá información específica.

La conexión a la biblioteca de postgres se realiza de la siguiente manera:

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

Como puede ver aquí, hay dos dependencias:

  • privilegios para la tabla pg_class: privilegios del usuario test1 en pg_class
  • Permisos del usuario test1 en el esquema grator

Luego, podemos mirar directamente los permisos correspondientes a estos dos objetos y eliminarlos.

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

En este momento, si se elimina el usuario, no habrá otras dependencias.

postgres=# drop user test1;
DROP USER

PD: ¿Cómo operamos si no conocemos el objeto específico y no podemos eliminarlo? Aquí construimos un caso como demostración, creamos un nuevo usuario test2 y le otorgamos el permiso de selección de otorgante. En este momento, no podemos dejar caer

testdb2=# drop user test2;
ERROR:  role "test2" cannot be dropped because some objects depend on it
DETAIL: 2 objects in database postgres

El almacenamiento interno real de las dependencias del usuario es la tabla del sistema pg_shdepend, que registra los oid y sus dependencias de cada objeto dependiente. Primero, obtenemos el oid del usuario y luego vamos a la tabla del sistema para encontrar el registro de dependencia correspondiente.

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。

Después de obtener el classid, este representa el id de la tabla de registro del objeto que depende del usuario actual, luego podemos encontrar esta dependencia en la tabla pg_class:

postgres=# select relname,relacl from pg_class where oid = 2615;
 relname | relacl
--------------+----------------
 pg_namespace | {=r/d00467397}
(1 row)

Bien, al ver que la tabla de registros es pg_namespace, se puede confirmar que el usuario dependiente es un esquema. Vaya a pg_namespace aquí, verifique el objid obtenido arriba y sabrá el objeto específico

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)

Aquí puede ver que hay dos esquemas, uno es el esquema con el mismo nombre que el usuario, y el otro es el otorgante que ha sido autorizado en este momento. Después de eliminar el autorizado, el usuario puede eliminarlo.

postgres=# revoke usage on schema grantor from test2;
REVOKE
postgres=# drop user test2;
DROP USER

 

Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud por primera vez~

Los graduados de la Universidad Popular Nacional robaron la información de todos los estudiantes de la escuela para construir un sitio web de puntuación de belleza, y han sido detenidos criminalmente.La nueva versión de Windows de QQ basada en la arquitectura NT se lanza oficialmente.Estados Unidos restringirá el uso de China de Amazon, Microsoft y otros servicios en la nube que brindan capacitación en modelos de IA. Se anunciaron proyectos de código abierto para detener el desarrollo de funciones LeaferJS , el puesto técnico mejor pagado en 2023, lanzado: Visual Studio Code 1.80, una biblioteca de gráficos 2D de código abierto y potente , compatible funciones de imagen de terminal . El número de registros de subprocesos ha superado los 30 millones. "Cambio" deepin adopta Asahi Linux para adaptarse a la clasificación de la base de datos Apple M1 en julio: Oracle aumenta, abriendo el puntaje nuevamente
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/4526289/blog/10086108
Recomendado
Clasificación