Derechos que poseen los usuarios de la Base de Datos

Deja un comentario

En este artículo ya habíamos visto lo que debemos hacer para conocer los nombres de todos los usuarios de nuestra Base de Datos:

Usuarios de nuestra Base de Datos

Pero a veces nos puede interesar conocer si un usuario tiene derechos (permisos, privilegios) sobre alguna tabla, vista o stored procedure, por ejemplo:

  • ¿SUSANA puede hacerle un SELECT a la vista V_ABM_VENDEDORES?
  • ¿SUSANA puede insertarle filas a la tabla VENTAS?
  • ¿GRACIELA puede ejecutar el stored procedure llamado GRABAR_VENDEDOR?

Toda esa información (y mucha más) la encontraremos en la tabla RDB$USER_PRIVILEGES, como vemos en la Captura 1. Queremos conocer cuales son los derechos del usuario WOJEDAR, para eso escribimos:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER = 'WOJEDAR'

Y estas son las primeras filas que obtenemos:

DERECHOS1

Captura 1. Si haces clic en la imagen la verás más grande

En la columna RDB$PRIVILEGE hay una letra que nos dice que derechos (permisos, privilegios) tiene el usuario:

  • I = INSERT
  • U = UPDATE
  • D = DELETE
  • S = SELECT
  • R = puede relacionar tablas mediante una FOREIGN KEY
  • X = puede ejecutar el stored procedure

El nombre de la tabla, la vista, o el stored procedure se guarda en la columna RDB$RELATION_NAME.

Entonces, para responder a la primera pregunta podríamos escribir algo como:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER_NAME = 'SUSANA' AND
   RDB$RELATION_NAME = 'VENDEDORES'

 Y si vemos una fila que tiene una letra «S» en la columna RDB$PRIVILEGE, entonces SUSANA sí puede hacerle un SELECT a la tabla VENDEDORES.

Conclusión:

Siempre es importante saber que derechos tiene cada usuario, si no queremos que el usuario MIRTHA tenga un derecho debemos verificar que ya no lo esté teniendo. Los derechos pueden ser otorgados por el usuario SYSDBA, por el creador de la Base de Datos o por cualquier usuario que tenga el rol RDB$ADMIN WITH GRANT OPTION. Si hay un problema de comunicación entre ellos entonces uno podría estar otorgándole un derecho a MIRTHA que MIRTHA no debería tener.

Para estar seguros de que MIRTHA tiene (o no tiene) un derecho lo que debemos hacer es consultar la tabla RDB$USER_PRIVILEGES, ya que es la única forma en que podremos estar 100% seguros de que tiene o no tiene ese derecho.

Artículos relacionados:

Usuarios de nuestra Base de Datos

El índice del blog Firebird21

Algo más sobre GRANT y ROLE

2 comentarios

Los conceptos sobre GRANT y sobre ROLE pueden ser un poco difíciles de entender para quienes nunca los habían usado, así que con este artículo trataré de aclarar algunos conceptos y dudas que se puedan tener:

  1. Cuando un usuario consigue conectarse a la Base de Datos eso significa que tanto su nombre como su contraseña están reconocidos por el Firebird.
  2. Sin embargo, el hecho de haberse conseguido conectar no implica que pueda ejecutar exitosamente algún comando. Si no tiene derechos (permisos, privilegios) en esa Base de Datos entonces todos sus intentos fallarán. Ni siquiera podrá hacer un SELECT.
  3. Para que el usuario pueda ejecutar exitosamente algún comando, alguien previamente tuvo que haberle otorgado ese derecho (permiso, privilegio).
  4. Ese «alguien» que le otorgó el derecho puede ser el usuario SYSDBA, el creador de la Base de Datos, o un usuario que tiene el rol RDB$ADMIN con la opción de otorgar derechos, nadie más.
  5. Un rol es un grupo de usuarios. Los derechos (permisos, privilegios) que se otorgan a un rol automáticamente se otorgan a todos los usuarios que se conectan usando ese rol
  6. Para que un usuario pertenezca a un rol otro usuario debió haberlo hecho miembro de ese rol. Ese «otro usuario» puede ser SYSDBA, el creador de la Base de Datos o un usuario que tiene el rol RDB$ADMIN con la opción de otorgar derechos, nadie más.
  7. Cuando un usuario se conecta a la Base de Datos puede hacerlo especificando un rol o sin especificar un rol.
  8. Si se conecta sin especificar un rol, entonces tendrá solamente los derechos que a él específicamente se le hayan otorgado
  9. Si se conecta especificando un rol entonces tendrá todos los derechos que se le otorgaron específicamente a él más todos los derechos que tiene ese rol
  10. Un usuario puede pertenecer a muchísimos roles pero cuando se conecta solamente puede elegir uno de ellos y solamente tendrá los derechos que le corresponden a ese rol.

Ejemplo:

Al usuario JUAN se le otorgó el derecho de hacer SELECT a la tabla CLIENTES.

Al rol R_CONTABILIDAD se le otorgó el derecho de hacer SELECT a la tabla VENTAS.

Al usuario JUAN se lo hizo miembro del rol R_CONTABILIDAD.

Si el usuario JUAN se conecta sin especificar un rol, entonces podrá hacer SELECT a la tabla CLIENTES pero no a la tabla VENTAS.

Si el usuario JUAN se conecta especificando el rol R_CONTABILIDAD entonces podrá hacer SELECT a la tabla CLIENTES y también a la tabla VENTAS.

El usuario JUAN no podrá hacer SELECT a la tabla COMPRAS porque ni a él ni al rol R_CONTABILIDAD se le otorgó el derecho de hacerle un SELECT a esa tabla. Si más adelante a él o al rol R_CONTABILIDAD se le otorga el derecho de SELECT a la tabla COMPRAS entonces cuando vuelva a conectarse podrá hacer el SELECT, pero mientras tanto le será imposible.

Recuerda:

Un rol es un grupo de usuarios, si varios usuarios necesitan tener los mismos derechos entonces ahorrarás mucho tiempo creando un rol con esos derechos y luego otorgándole ese rol a cada usuario. Si no creas un rol entonces podrías olvidarte de asignarle un derecho a un usuario y además escribirás mucho más y en consecuencia perderás mucho tiempo.

Muy importante:

En general, por motivos de seguridad, lo recomendable es que no se otorguen derechos específicos a los usuarios sino a los roles. De esta manera si un usuario se conecta sin especificar un rol nada podrá hacer en la Base de Datos, ni siquiera un SELECT. Por lo tanto, siempre deberá conectarse usando un rol y en ese caso solamente tendrá los derechos (permisos, privilegios) que se le hayan otorgado al rol con el cual se conectó.

Artículos relacionados:

Entendiendo los derechos de acceso

Otorgando permisos con EMS SQL Manager

Delegando el otorgamiento de derechos

Un stored procedure para otorgarle TODOS los derechos a un usuario

El índice del blog Firebird21

 

Un stored procedure para otorgarle TODOS los derechos a un usuario

6 comentarios

En ocasiones queremos que un usuario (o un rol) tenga todos los derechos sobre una Base de Datos aunque sin ser el SYSDBA de ella ni tener el rol RDB$ADMIN. O quizás lo que necesitamos es que tenga la mayoría de los derechos, aunque no todos.

Para este último caso lo que podríamos hacer es otorgarle todos los derechos y luego quitarle algunos de ellos, para que él tenga solamente los derechos que nosotros queremos que tenga.

Tenemos dos formas de conseguir nuestro objetivo:

  1. La forma lenta
  2. La forma rápida

La forma lenta es por cada tabla, por cada vista y por cada stored procedure otorgarle el derecho correspondiente. Desde luego que si las tablas, vistas y stored procedures se cuentan por decenas o por centenas hacer algo así será terriblemente aburrido y una gran pérdida de tiempo que podríamos aprovechar haciendo algo más productivo.

La forma rápida es a través de un stored procedure como el siguiente:

CREATE PROCEDURE SP_GRANT_ALL_TO(
   tcNombreUsuario VARCHAR(31))
AS
   DECLARE VARIABLE tcObjeto VARCHAR(31);
BEGIN

   -- Se otorga derechos sobre las tablas y sobre las vistas

   FOR SELECT
      RDB$RELATION_NAME
   FROM
      RDB$RELATIONS
   WHERE
      RDB$SYSTEM_FLAG = 0
   INTO
      :tcObjeto
   DO
      EXECUTE STATEMENT 'GRANT ALL ON ' || tcObjeto || ' TO ' || tcNombreUsuario;

   -- Se otorga derechos sobre los stored procedures

   FOR SELECT
      RDB$PROCEDURE_NAME
   FROM
      RDB$PROCEDURES
   WHERE
      RDB$SYSTEM_FLAG = 0
   INTO
      :tcObjeto
   DO
      EXECUTE STATEMENT 'GRANT EXECUTE ON PROCEDURE ' || tcObjeto || ' TO ' || tcNombreUsuario;

END;

 Este stored procedure le otorga al usuario o al rol cuyo nombre introducimos todos los derechos sobre todas las tablas, sobre todas las vistas y sobre todos los stored procedures de nuestra Base de Datos. Lo llamaríamos así:


EXECUTE PROCEDURE SP_GRANT_ALL_TO('MARCELA');

EXECUTE PROCEDURE SP_GRANT_ALL_TO('R_CONTABILIDAD');

COMMIT;

Y cuando el usuario MARCELA o alguien que pertenezca al rol R_CONTABILIDAD vuelva a conectarse a la Base de Datos, tendrá acceso a todas las tablas, todas las vistas y todos los stored procedures.

Conclusión:

Otorgar los derechos (también llamados permisos o privilegios) a cada tabla, cada vista, y cada stored procedure puede ser extremadamente tedioso, sobre todo cuando los objetos no son dos o tres sino decenas o centenas. Evidentemente que lo más inteligente es tener un stored procedure que se encargue de esa tarea por nosotros.

El stored procedure aquí mostrado cumple con esa tarea, aunque desde luego que podría ser mejorado o adaptado a tus particulares circunstancias. Por ejemplo podrías agregarle WITH GRANT OPTION, o podrías colocar un IF …. THEN para que algunos objetos sean salteados y no se otorgue permisos sobre ellos, algo como:

IF (tcObjeto <> 'CONFIGURACION') THEN
   EXECUTE STATEMENT 'GRANT ALL ON ' || tcObjeto || ' TO ' || tcNombreUsuario;

Aquí, si la tabla se llama CONFIGURACION entonces el usuario no recibe derechos en esa tabla. Recibe derechos sobre todas las otras tablas, pero no sobre la tabla CONFIGURACION. Eso puede ser lo más adecuado para evitar que meta sus pezuñas donde no debe.

Otro método es usar el comando REVOKE para quitarle derechos que anteriormente se le habían otorgado. Sería algo como:

REVOKE ALL ON CONFIGURACION FROM MARCELA

Tanto usando IF … THEN como usando REVOKE ALL, se consigue el objetivo buscado, o sea que el usuario MARCELA no tenga derechos sobre la tabla CONFIGURACION.

Ya tú decidirás cual te resulta más conveniente usar.

Advertencia:

El hecho de que PUEDAS fácilmente otorgarle todos los derechos sobre todos los objetos a un usuario usando un stored procedure como el aquí mostrado no significa que DEBAS hacerlo. La seguridad y la integridad de tu Base de Datos siempre debe ser tu principal prioridad; tu comodidad o la comodidad de los usuarios, debe estar después.

Muchas veces lo preferible es que crees un rol (o varios roles) y uno (o varios) archivos de script para el otorgamiento de derechos. Eso tiene la ventaja de que te sirve como documentación (ya que en tu archivo de script puedes escribir todos los comentarios que desees) y que con simples «copiar y pegar» puedes rápidamente tener muchos archivos de script, cada uno de ellos otorgando o revocando derechos.

Por lo tanto, el stored procedure anteriormente mostrado puede ser muy útil pero siempre deberías verificar que no estás otorgando más derechos de los que deberías otorgar.

Artículos relacionados:

Entendiendo los derechos de acceso

Otorgando permisos con EMS SQL Manager

Delegando el otorgamiento de derechos

El índice del blog Firebird21

 

Delegando el otorgamiento de derechos

9 comentarios

Lo usual es que el creador de la Base de Datos o el usuario SYSDBA se encarguen de otorgarles derechos (también llamados «permisos» o «privilegios») a los usuarios y a los roles. Sin embargo, en organizaciones grandes esto puede requerir de mucho tiempo entonces tienen la posibilidad de delegar parte de su autoridad en otros usuarios, para que estos otros usuarios también puedan otorgar derechos.

El comando que sirve para otorgar derechos se llama GRANT. A su vez, el comando que sirve para quitar derechos se llama REVOKE y sus sintaxis son las siguientes:

GRANT
   {<privilegios> ON <objeto> | rol}
   TO <beneficiario>
   [WITH {GRANT|ADMIN} OPTION]
   [{GRANTED BY | AS} [USER] otorgador]
REVOKE
   [{GRANT|ADMIN} OPTION FOR]
   {<privilegios> ON <objeto> | rol}
   FROM <beneficiario>
   [{GRANTED BY | AS} [USER] otorgador]

La clásula WITH GRANT OPTION significa que el usuario que recibió ese derecho puede otorgarlo a otros usuarios, si lo desea. Desde luego que solamente puede otorgar los derechos que posee y nada más.

La cláusula WITH ADMIN OPTION se otorga a los roles y significa que el usuario que tiene un rol puede otorgar ese rol a otros usuarios, si lo desea. Por supuesto que solamente puede otorgar su propio rol y nada más.

La cláusula GRANTED BY se usa para que aparezca como otorgador del derecho no quien lo hizo, sino otro usuario. ¿Y por qué se haría eso? Para que ese otro usuario pueda revocar el derecho.

Existe un rol especial, llamado RDB$ADMIN, que le permite a quien lo recibe tener los mismos derechos que el usuario SYSDBA pero solamente en esta Base de Datos. O sea que en la práctica quien posee el rol RDB$ADMIN puede actuar como si fuera el usuario SYSDBA.

Ejemplos:

Conectado como SYSDBA:

GRANT SELECT ON BANCOS TO MARCELA WITH GRANT OPTION;

SYSDBA le otorgó a MARCELA el derecho de hacer SELECT en la tabla BANCOS y también le permite a MARCELA otorgar ese derecho a otros usuarios.

GRANT R_CONTABILIDAD TO SILVIA WITH ADMIN OPTION;

SYSDBA le otorgó a SILVIA el rol R_CONTABILIDAD y también le permite asignar ese rol a otros usuarios.

GRANT RDB$ADMIN TO FATIMA

SYSDBA le otorgó a FATIMA el rol RDB$ADMIN el cual le permite a FATIMA tener todos los derechos sobre todos los objetos de esta Base de Datos. En otras palabras: FATIMA es exactamente igual que SYSDBA en esta Base de Datos, puede hacer todo lo que SYSDBA puede hacer.

GRANT R_CONTABILIDAD TO MARCELA WITH ADMIN OPTION GRANTED BY FATIMA;

SYSDBA le otorgó a MARCELA el rol R_CONTABILIDAD y también le permite otorgar ese rol a otros usuarios, pero lo hizo en nombre de FATIMA. ¿Por qué en nombre de FATIMA? Para que FATIMA pueda, si lo desea, quitarle ese rol a MARCELA.

 Conectado como MARCELA:

GRANT SELECT ON BANCOS TO DIANA;

MARCELA tiene el derecho de otorgar el SELECT a la tabla BANCOS, así que se lo otorga a DIANA. Desde ahora ambas (MARCELA y DIANA) pueden hacer SELECT a la tabla BANCOS.

GRANT INSERT ON BANCOS TO DIANA;

Esto falla y será rechazado por el Firebird porque MARCELA no tiene el derecho de otorgar INSERT en la tabla BANCOS. Ella tiene el derecho de otorgar SELECT en la tabla BANCOS pero no tiene el derecho de otorgar INSERT en la tabla BANCOS y por lo tanto no se le permitirá hacerlo.

GRANT ALL ON BANCOS TO DIANA;

Esto falla por la misma razón: MARCELA solamente puede otorgar el derecho de SELECT y ninguno más. Si intenta otorgar otro derecho entonces será rechazada. Aquí intentó otorgar todos los derechos y fue rechazada.

GRANT SELECT ON PRODUCTOS TO DIANA;

Esto también fallará, porque MARCELA puede otorgar el derecho de hacer SELECT en la tabla BANCOS, pero no puede otorgar el derecho de SELECT en la tabla PRODUCTOS, nunca se le otorgó ese derecho y ella no puede otorgar un derecho que no posee.

REVOKE SELECT ON BANCOS FROM DIANA;

MARCELA le había otorgado el derecho de hacer SELECT en la tabla BANCOS a DIANA, así que MARCELA puede quitarle ese derecho. Desde este momento DIANA ya no podrá hacer SELECT a la tabla BANCOS.

Conectado como SILVIA

GRANT R_CONTABILIDAD TO DIANA;

SILVIA le otorgó el rol R_CONTABILIDAD a DIANA, desde ahora DIANA ya es miembro de ese rol.

GRANT R_CONTABILIDAD TO MIRTHA WITH ADMIN OPTION;

SILVIA le otorgó el rol R_CONTABILIDAD a MIRTHA y también le dió el derecho de asignar ese rol a otros usuarios.

Conectado como FATIMA

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto falla, no se le permite a FATIMA otorgarle derechos sobre la tabla PRODUCTOS a MIRTHA. ¿Y por qué falla, acaso FATIMA no posee el rol RDB$ADMIN? Sí, pero no lo usó en el momento de conectarse, por eso falló el GRANT.

Conectado como FATIMA y usando el rol RDB$ADMIN

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto sí funciona ok porque ahora FATIMA se conectó usando el rol RDB$ADMIN y por lo tanto en esta Base de Datos tiene exactamente los mismos derechos que el usuario SYSDBA.

Artículos relacionados:

Agregando, modificando y borrando usuarios

El índice del blog Firebird21

Otorgando permisos con EMS SQL Manager

3 comentarios

Como hemos visto en este artículo:

https://firebird21.wordpress.com/2013/05/29/entendiendo-los-derechos-de-acceso/

A los usuarios, a los roles y a los objetos (vistas, triggers, database triggers, stored procedures) se les puede otorgar permisos sobre las tablas y sobre los stored procedures.

Para ello podemos utilizar el programa ISQL (que viene incluido con el Firebird) o algún programa de administración gráfica.

En la imagen de abajo vemos como usaríamos el programa ISQL para ese efecto:

GRANT1

(haciendo clic en la imagen la verás más grande)

Si usamos el programa EMS SQL Manager también podemos otorgar permisos, para ello hacemos clic con el botón derecho sobre el nombre de la tabla o del stored procedure, luego elegimos la opción «Tasks» (tareas) y luego la opción «Grants for table…» como podemos ver en la imagen de abajo:

GRANT2

(haciendo clic en la imagen la verás más grande)

 Y ahora la pantalla cambiará para mostrarnos algo similar a esto:

GRANT3

(haciendo clic en la imagen la verás más grande)

 Para otorgale permisos a un usuario hacemos clic sobre su nombre y luego sobre la operación que le queremos otorgar o sobre las opciones que vemos a la izquierda. Por ejemplo, para otorgarle al usuario «Silvia» el derecho de SELECT sobre la tabla PRODUCTOS haríamos clic allí.

GRANT4

(haciendo clic en la imagen la verás más grande)

Fácilmente podemos saber si el usuario «Silvia» tiene un permiso mirando el color del botón. Si es rojo, no lo tiene.

Para otorgarle todos los permisos podemos hacer clic sucesivamente en cada botón o elegir la opción «Grant all» que se encuentra a la izquierda:

GRANT5

(haciendo clic en la imagen la verás más grande)

Después de hacer clic sobre la opción «Grant all» esto es lo que vemos (todos los colores de los botones han cambiado y también las opciones mostradas a la izquierda han cambiado)

GRANT7

(haciendo clic en la imagen la verás más grande)

Si queremos  quitarle todos los permisos utilizaríamos la opción «Revoke all»

Importante:

Para que la acción de otorgar o de quitar permisos funcione debemos hacer clic sobre la opción «Compile». Recién después de hacer clic sobre «Compile» el usuario tendrá o dejará de tener los permisos.

GRANT6

(haciendo clic en la imagen la verás más grande)

 Resumiendo:

  • Si el botón es de color verde, tiene el permiso
  • Si el botón es de color rojo, no tiene el permiso
  • Para otorgarle todos los permisos podemos hacer clic sobre la opción «Grant all»
  • Para quitarle todos los permisos podemos hacer clic sobre la opción «Revoke all»
  • Si elegimos «with grant option» significa que el usuario puede otorgar ese mismo permiso a otros usuarios
  • Para que el usuario tenga o deje de tener estos permisos debemos hacer clic sobre la opción «Compile»

Entendiendo los derechos de acceso

9 comentarios

En este artículo hemos visto como agregar usuarios, borrar usuarios, y cambiarles la contraseña:

https://firebird21.wordpress.com/2013/04/21/agregando-modificando-y-borrando-usuarios/

Esas personas podrán acceder a la Base de Datos pero aún no podrán realizar alguna operación en ella, ni siquiera una consulta. El Firebird por defecto les impide que ejecuten los comandos INSERT, UPDATE, DELETE, SELECT, EXECUTE PROCEDURE.

¿Por qué eso?

Porque para mantener el acceso y la utilización de la Base de Datos seguros los usuarios deben tener permisos solamente a las operaciones que específicamente se les hayan otorgado. Si no se les otorgó el permiso para realizar una operación, no podrán realizar esa operación.

Por ejemplo, a los vendedores no se les otorga el permiso para modificar los precios de venta de los productos; a los empleados no se les otorga el permiso para cambiar su propio sueldo; a los contadores no se les otorga el permiso de cambiar los datos de una venta; etc.

Si intentan realizar una operación a la cual no tienen permiso, el Firebird lo impedirá.

¿Qué es un rol?

Es el nombre otorgado a un grupo de usuarios que tienen exactamente los mismos permisos. Por ejemplo, se podría tener un rol llamado R_VENDEDORES en el cual se especificarán los permisos que poseen las personas que tienen ese rol. Todas las personas cuyo rol sea R_VENDEDORES tendrán esos permisos pero ninguno más. A los miembros de este rol se les podrían otorgar el permiso de insertar ventas (pero no modificarlas ni borrarlas), el permiso de consultar las cantidades en stock y los precios de venta de los productos (pero no insertar ni modificar ni borrar los datos de los productos). A los miembros de este rol no se les permitirá ver las compras ni las cobranzas ni los pagos ni los sueldos ni las comisiones de otros vendedores ni muchas otras cosas más.

¿Cómo se crea un rol?

Con el comando CREATE ROLE NombreRol

¿Cómo se elimina un rol?

Con el comando DROP ROLE NombreRol

¿Cuál es el comando usado para otorgarles permisos a los usuarios y a los roles?

El comando se llama GRANT (conceder, otorgar, en castellano) y su sintaxis es la siguiente:

GRANT
{<permisos> ON <objeto> | rol}
TO <concedido>
[WITH {GRANT|ADMIN} OPTION]
[{GRANTED BY | AS} [USER] otorgador]

¿Cuáles son los permisos que se pueden otorgar?

SELECT
Consultar datos
INSERT
Agregar nuevas filas
UPDATE
Modificar datos existentes
DELETE
Borrar filas
REFERENCES
Referirse a una Primary Key desde una Foreign Key. Siempre se debe 
otorgar este permiso para que puedan seleccionarse las columnas de 
la tabla referida.

ALL
Todos los anteriores

EXECUTE
Ejecuta un stored procedure o lo llama usando SELECT cuando se 
trata de un stored procedure seleccionable

ROLE
Adquiere todos los privilegios otorgados al rol. Una vez que un 
rol existe y se le han otorgado permisos, se convierte en un 
permiso que se les puede otorgar a los usuarios.

¿Qué significa WITH GRANT OPTION?

Que el usuario a quien se le otorgó ese permiso tiene el derecho de otorgarles ese mismo permiso a otros usuarios.

¿Cómo se quita un permiso?

 Con el comando REVOKE.

REVOKE <permisos>

ON <objeto>

FROM <revocado>

 Ejemplo 1. Otorgando el permiso de hacer SELECT a la tabla PRODUCTOS al usuario ALICIA

GRANT SELECT ON PRODUCTOS TO ALICIA

Ejemplo 2. Otorgando los permisos de SELECT y de INSERT y de UPDATE a la tabla PRODUCTOS al usuario SUSANA

GRANT INSERT, UPDATE, SELECT ON PRODUCTOS TO SUSANA

Ejemplo 3. Otorgando todos los permisos a la tabla PRODUCTOS al usuario GRACIELA

GRANT ALL ON PRODUCTOS TO GRACIELA

Ejemplo 4. Otorgando el permiso de cambiar el Código de Barras y el Precio de Venta de los productos al usuario INES

GRANT UPDATE (PRD_CODBAR, PRD_PREVTA) ON PRODUCTOS TO INES

Ejemplo 5. Otorgando el permiso de ejecutar el stored procedure GRABAR_PRODUCTO al usuario RAQUEL

GRANT EXECUTE ON PROCEDURE GRABAR_PRODUCTO TO RAQUEL

Ejemplo 6. Recibiendo y otorgando el permiso de hacer SELECT a la tabla PRODUCTOS

GRANT SELECT ON PRODUCTOS TO SILVIA WITH GRANT OPTION

Y ahora Silvia puede escribir:

GRANT SELECT ON PRODUCTOS TO MARCELA

GRANT SELECT ON PRODUCTOS TO LUCIANA WITH GRANT OPTION

Ejemplo 7. Otorgando permisos a un stored procedure

GRANT INSERT, UPDATE ON PRODUCTOS TO PROCEDURE GRABAR_PRODUCTO

En este ejemplo al stored procedure GRABAR_PRODUCTO se le otorgó el permiso de INSERT y de UPDATE a la tabla PRODUCTOS. Eso significa que si un usuario tiene el permiso de ejecutar el stored procedure también tendrá el permiso se insertar y de actualizar la tabla respectiva. Si no se hace así entonces habrá que asignarle a cada usuario individualmente (y a cada rol individualmente) los derechos de insertar y de actualizar la tabla, y eso llevaría mucho más tiempo.

GRANT ALL ON PRODUCTOS TO PROCEDURE RECALCULAR_SALDOS

En este ejemplo al stored procedure RECALCULAR_SALDOS se le otorgaron todos los permisos sobre la tabla PRODUCTOS. O sea que dentro de ese stored procedure se puede insertar, modificar, borrar, seleccionar datos y referenciar tablas.

Ejemplo 8. Otorgando los permisos a varios usuarios a la vez

GRANT SELECT ON PAISES TO ALICIA, GRACIELA, SILVIA, SUSANA

Estos cuatro usuarios podrán realizar consultas a la tabla PAISES

Ejemplo 9. Creando roles

CREATE ROLE R_ADMINISTRACION

CREATE ROLE R_VENDEDORES

(El nombre del rol no tiene por qué empezar con R_, esa es solamente una costumbre del autor de este blog, si quieres a tu rol lo puedes llamar: ADMINISTRACION, CONTADORES, VENDEDORES, etc., pero si el nombre empieza con R_ es más fácil saber que se trata de un rol)

Ejemplo 10. Otorgándole permisos al rol

GRANT UPDATE(PRD_PREVTA) ON PRODUCTOS TO R_ADMINISTRACION

GRANT INSERT, SELECT ON PRODUCTOS TO R_VENDEDORES

Ejemplo 11. Quitándole el permiso de hacer SELECT a la tabla PRODUCTOS al usuario ALICIA

REVOKE SELECT ON PRODUCTOS FROM ALICIA

Ejemplo 12. Quitándole todos los permisos a la tabla PRODUCTOS al usuario SUSANA

REVOKE ALL ON PRODUCTOS FROM SUSANA

Ejemplo 13. Quitándole el derecho de ejecutar el stored procedure GRABAR_PRODUCTO al usuario RAQUEL

REVOKE EXECUTE ON PROCEDURE GRABAR_PRODUCTO FROM RAQUEL

Ejemplo 14. Quitándole el derecho de otorgar permisos al usuario SILVIA

REVOKE GRANT OPTION FOR SELECT ON PRODUCTOS FROM SILVIA

Artículo relacionado:

El índice del blog Firebird21