GRANT CREATE USER / GRANT DROP USER

Uno tiende a pensar en los ‘GRANTs’ de tipo ‘CREATE / DROP’ como dos caras de la misma moneda. Esto es así en la mayoría de los casos, pero a veces hay excepciones que están ahí ocultas, esperando su ocasión para hacerte perder un buen rato mientras intentas comprender dónde está el error en el proceso que acabas de desarrollar y que no hace más que lanzar errores en la ejecución, aunque tú has tenido en cuenta todos los factores y tu planteamiento es, al menos a primera vista, irreprochable.

Esto es lo que me ha pasado últimamente con unos procesos de creación de usuarios que antes efectuábamos de forma manual y ahora han pasado a ser ejecutados de forma automática mediante ‘scripts’.

La historia completa es esta:

Una de las fuentes nos envía regularmente un fichero con una lista de usuarios que hay que gestionar. Nosotros, que somos muy ordenados, habíamos creado un usuario ‘padre’ desde el que se creaban (‘CREATE USER … FROM’) y eliminaban (‘DROP USER …’) estos usuarios. Por motivos que no vienen al caso, este proceso se hacía mediante el usuario ‘DBC’ y, claro, no había mayor problema.

El caso es que para la automatización de los procesos se comenzó a utilizar este usuario ‘PADRE’, así que lo primero que se hizo sobre el mismo fue otorgarle los privilegios de ‘CREATE USER’ y ‘DROP USER’ que no tenía (no habían hecho falta) sobre su propio usuario/base de datos.

Así pues, se ejecutó ‘GRANT CREATE USER ON USUARIO_PADRE TO USUARIO_PADRE’ y ‘GRANT DROP USER ON USUARIO_PADRE TO USUARIO_PADRE’ sin mayor problema.

So far, so good. De hecho, la parte correspondiente a la creación de nuevos usuarios iba como la seda, pero la cosa comenzó a torcerse cuando con las primeras ejecuciones de los procesos automáticos, éstos comenzaron a dar errores en la parte de eliminación de usuarios ‘hijo ‘del tipo:

.LOGON DWH/USUARIO_PADRE,

 *** Logon successfully completed.
 *** Teradata Database Release is 12.00.02.46
 *** Teradata Database Version is 12.00.02.46
 *** Transaction Semantics are BTET.
 *** Character Set Name is 'ASCII'.

 *** Total elapsed time was 1 second.

+---------+---------+---------+---------+---------+---------+---------+----
DROP USER USUARIO_HIJO_0001;
 *** Failure 3524 The user does not have DROP USER access to database USUARIO_HIJO_0001.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

+---------+---------+---------+---------+---------+---------+---------+----
.QUIT ERRORLEVEL
 *** You are now logged off from the DBC.
 *** Exiting BTEQ...
 *** RC (return code) = 8

¿Pero por qué? ¡Si le hemos dato un ‘GRANT DROP USER’ sobre toda la base de datos ‘USUARIO_PADRE’!

Con un vistazo a los permisos sobre las bases de datos de los usuarios hijo vimos que sólo las nuevas (es decir, las creadas mediante los procesos automáticos con ‘USUARIO_PADRE’) mostraban que dicho USUARIO_PADRE tenía privilegios ‘DROP USER’ sobre ellas.

Por supuesto, lo primero -y estúpido- fue repetir ‘GRANT DROP USER ON USUARIO_PADRE TO USUARIO_PADRE’, por si la base de datos no lo había entendido la primera vez o si simplemente había pasado de nosotros…

Ni que decir tiene que la siguiente ejecución de los procesos automáticos volvió a dar los mismos errores de la primera vez.

Así que lo siguiente fue dar los privilegios de eliminación UNO POR UNO sobre todos los usuarios hijos:

‘GRANT DROP USER ON USUARIO_HIJO_0001 TO USUARIO_PADRE’
‘GRANT DROP USER ON USUARIO_HIJO_0002 TO USUARIO_PADRE’
‘GRANT DROP USER ON USUARIO_HIJO_0003 TO USUARIO_PADRE’

Y, claro, así sí funcionaba todo OK. Pero la pregunta era ¿por qué? ¿Por qué uno a uno sí, pero cuando dábamos el privilegio sobre toda la base de datos ‘padre’ aquello no iba?

Pues porque este era uno más de esos casos en que el planteamiento está bien, lo que están mal son las premisas.

Así que, un poco de cultura leyendo la documentación:

CREATE USER – Automatic Rights

By issuing a CREATE USER statement, the CREATOR causes Automatic rights to be generated for both the created user and the creator.

SYSDBA
| SYSDBA creates a new user named Accounting.
|
Accounting

Both SYSDBA and Accounting are given the following rights over Accounting:

CREATE Table
DROP Table
CREATE View
DROP View
CREATE Macro
DROP Macro
CREATE Trigger
DROP Trigger
SELECT
INSERT
UPDATE
DELETE
EXECUTE
DROP Procedure
DROP Function
DUMP
RESTORE
CHECKPOINT
CREATE Authorization
DROP Authorization

SYSDBA is given the following additional rights over Accounting:

CREATE Database
DROP Database
CREATE User
DROP User

Y además:

To create a user, you must have the CREATE USER privilege on the immediate owner database or user. Newly created users receive the privileges listed in “Automatic Privileges For Created User/Database” on page 143.

To modify or drop a user, you must have the DROP USER privilege.

Ahí está la respuesta: Cuando un usuario crea otro, tiene automáticamente privilegios de eliminarlo. Y lo que es más importante: el privilegio ‘CREATE USER’ permite crear usuarios en ese usuario/base de datos, pero ‘DROP USER’ no significa privilegios para eliminar los usuarios hijos, sino privilegios para eliminar ese y sólo ése usuario.

Por eso, cuando ejecutamos ‘GRANT DROP USER ON USUARIO_PADRE TO USUARIO_PADRE’ lo único que estábamos haciendo era darle al usuario ‘USUARIO_PADRE’ privilegios para borrar su propio usuario. Ese privilegio era, pues, totalmente superfluo. La única forma de borrar los usuarios hijos era teniendo dicho privilegio ‘DROP USER’ sobre todos y cada uno de ellos.

Nota: con agradecimientos a mi compañera C. que con sus consejos me puso en el camino correcto.

Saludos.

Carlos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: