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

 

Anuncios

¿Cuándo se actualiza la estructura de una tabla?

4 comentarios

Si con un programa cambias la estructura de una tabla y con otro programa quieres usar esos cambios notarás que a veces no puedes hacerlo.

Veamos un ejemplo:

El usuario ejecuta su programa de Contabilidad y está trabajando con ese programa. Quiere introducir el nombre de un Proveedor y la columna le queda corta, digamos que solamente puede introducir 25 caracteres y él necesita introducir 31. Te llama y tú le dices: “ok, no hay problema, ya te actualizo la estructura de la tabla”.

Entonces vas, abres el EMS SQL Manager (o cual sea tu administrador gráfico), y cambias el ancho de la columna a 40, compilas la tabla, y está todo ok. Haces una prueba modificando esa columna en una fila cualquiera para que tenga 40 caracteres, le haces el COMMIT correspondiente y todo bien, funcionó perfecto. Desde luego, para terminar tu prueba borras los caracteres que le habías agregado a esa columna para probar, para que no queden registrados.

Ya has comprobado que aumentar el tamaño de la columna funcionó perfectamente entonces le llamas al usuario, y le dices: “ya está, ya podrás introducir hasta 40 caracteres en esa columna”.

El usuario feliz intenta nuevamente grabar los 31 caracteres que necesitaba grabar y … ¡¡¡NO FUNCIONA!!!

Te llama y te dice: “sigue sin funcionar, está igual que antes”

Entonces tú como eres muy educado a él no le dices una palabra pero dentro tuyo piensas: “¡¡¡la regranp…que lo recontraparió!!! ¡¡¡CÓMO QUE NO FUNCIONA!!! ¡¡¡Acabo de probar y funcionaba perfecto!!!”

Vuelves a probar y funciona bien. El usuario vuelve a probar y no le funciona.

¿Qué está pasando, cuál es el problema?

Que en tu programa los cambios sí funcionan, pero en el programa del usuario no. ¿Por qué?

Porque tú mantienes abierta a la Base de Datos en tu EMS SQL Manager (o cual sea tu administrador gráfico) y por lo tanto el usuario no se enterará de los cambios que hiciste hasta que no cierres la Base de Datos o salgas de ese programa.

Y en ocasiones, puede requerirse que el usuario también salga de su programa y vuelva a entrar.

Conclusión:

Que tú hagas un cambio a la estructura de una tabla no significa que al instante todos los usuarios se enteran de ese cambio, no es así. Para que se enteren debes salir del programa que usaste para realizar los cambios (el EMS SLQ Manager, el IBEXPERT, el FlameRobin, etc.) y en ocasiones el usuario también deberá salir del programa que él estaba usando. Solamente después de eso los cambios a la estructura de la tabla serán visibles.

Así que si haces cambios a una tabla y el usuario no ve esos cambios, no te desesperes. Simplemente sal de tu administrador gráfico y pídele al usuario que también salga del programa que estaba usando; cuando vuelva a entrar el asunto estará solucionado.

Artículo relacionado:

El índice del blog Firebird21