Interbase – GRANT Concesión de privilegios

Written by lopezatienza on 23/12/2008 – 16:35 -

GRANT : Concesión de privilegios.

Usaremos GRANT para dar a un usuario u objeto privilegios sobre una tabla, vista o rol. Como mínimo, GRANT necesita los siguientes parámetros:

  • Un privilegio de acceso: SELECT, UPDATE ...
  • La tabla sobre la que se permite ese privilegio.
  • El nombre del usuario que se le concede ese privilegio.

El usuario es un usuario definido en Interbase (lo veremos posteriormente).

La sintaxis es la siguiente:

GRANT{

<privileges> ON [TABLE] {tablename | viewname}

TO {<object> | <userlist> | GROUP UNIX_group}

| <role_granted> TO {PUBLIC | <role_grantee_list>}};

<privileges> = ALL [PRIVILEGES] | <privilege_list>

<privilege_list> = {SELECT

| DELETE

| INSERT

| UPDATE [(col [, col …])]

| REFERENCES [(col [, col …])]

}

[, <privilege_list> …]

<object> = { PROCEDURE procname

| TRIGGER trigname

| VIEW viewname

| PUBLIC

}

[, <object> …]

<userlist> = {[USER] username

| rolename

| UNIX_user

}

[, <userlist> …]

[WITH GRANT OPTION]

<role_granted> = rolename [, rolename …]

<role_grantee_list> = [USER] username [, [USER] username …]

[WITH ADMIN OPTION]

 

Conceder el privilegio de crear una clave ajena que referencia la clave primaria de departamentos aunque no sea el propietario de la tabla departamentos a emil:

GRANT REFERENCES ON DEPARTMENTS(DEPT_NO) TO EMIL;

Conceder el privilegio de selección para la tabla departamentos a emil:

GRANT SELECT ON DEPARTMENTS TO EMIL;

Garantizar el acceso con privilegio de referenciar o actualizar a columnas de una tabla, con esto podemos afinar el nivel de privilegios:

GRANT UPDATE (CONTACT, PHONE) ON CUSTOMERS TO PUBLIC;

Asignar privilegios a un procedimiento almacenado o trigger:

GRANT INSERT ON ACCOUNTS TO PROCEDURE MONEY_TRANSFER;

Grant execute on money_transfer to emil;

Grant insert on accounts to emil

Con esta operación podemos hacer que los usuarios accedan a tablas sin necesidad de tener permisos directos sobre las tablas, sino sobre los procedimientos almacenados que las controlan.

Hasta ahora hemos dado privilegios unicos a usuarios o procedimientos únicos, Veamos algunos ejemplos con varios privilegios y usuarios:

GRANT INSERT, UPDATE ON DEPARTMENTS TO FRANCIS, BEATRICE, HELGA;

GRANT INSERT, UPDATE ON DEPARTMENTS TO PROCEDURE ACCT_MAINT,MONEY_TRANSFER;

Si nos interesa asignar privilegios a TODOS los usuarios entonces:

GRANT SELECT, INSERT, UPDATE ON DEPARTMENTS TO PUBLIC;

Ahora vamos a usar los roles para asignar privilegios a grupos de posibles usuarios. Hemos de decir que Interbase en conjunción con UNIX permite que los grupos definidos en /etc/group puedan ser referenciados para asignar usuarios, así como individualmente, es decir, está ligado la gestión de usuarios con el S.O. UNIX  pero no ocurre lo mismo con Windows.

ROLES

Para trabajar con roles necesitaremos cuatro pasos:

  • Crear el rol con la sentencia CREATE ROLE.

CREATE ROLE rolename;

  • Conceder el uso del rol a los usuarios usando GRANT nombre de rol TO usuarios.

GRANT rolename TO usuarios;

  • Asignar privilegios a el rol usando GRANT  privilegio TO  nombre de rol El rol puede ser concedido con la opción WITH ADMIN OPTION  que permite a los usuarios asignar el rol o sólo con la opción WITH GRANT OPTION que permite a los usuarios asignar los privilegios a otros.

GRANT privilegio ON table TO nombre de rol;

  • Especificar el rol que se usa cuando un usuario accede a una base de datos.

CONNECT 'database' USER 'username' PASSWORD 'password' ROLE 'rolename';

Sintaxis para la asignación de privilegios a un rol que ha sido creado:

GRANT <privileges> ON [TABLE] {tablename | viewname}

TO rolename;

<privileges> = ALL [PRIVILEGES] | <privilege_list>

<privilege_list> = {SELECT

| DELETE

| INSERT

| UPDATE [(col [, col …])]

| REFERENCES [(col [, col …])]

}

[, <privilege_list> …]

Una vez que el rol ha sido creado y tenemos unos privilegios definidos para ese rol,  podemos conceder ese rol a varios usuarios, que adquieren los privilegios que han sido asignados al rol. Si queremos que el usuario conceda el rol a otros debemos incluir la sentencia WITH ADMIN OPTION.

GRANT {rolename [, rolename …]} TO {PUBLIC | {[USER] username [, [USER] username …]}

[WITH ADMIN OPTION];

Ejemplo, creamos un rol TODO, asignamos todos los privilegios y se lo pasamos a RENEE.

CREATE ROLE TODO;

GRANT ALL ON DEPARTMENTS TO TODO;

GRANT TODO TO RENEE;

Cuando trabajamos con roles, un usuario se debe conectar a la base de datos especificando un rol único. Si desea conectarse usando otro rol, antes debemos desconectarnos, no existe la posibilidad de cambiar de rol mientras estamos conectados.

Para conectarnos como usuario asociado a un rol podemos usar la sentencia CONNECT como en el ejemplo siguiente:

CONNECT 'basededatos.gdb' USER 'user1' PASSWORD 'secreto' ROLE rol1;

O tambien usando el campo rol en la secuencia de conexión a una base de datos en IbConsole con la opción “connect as”.

Tengo privilegios y los puedo conceder.

Si, un usuario puede tener privilegios y concederlos a otros usuarios, siendo estos privilegios acumulativos incluso. Todo esto se consigue con la opción WITH GRANT OPTION al final de la cláusula GRANT. No podemos hacerlo con un procedimiento almacenado.

En definitiva, un usuario puede asignar privilegios a las tablas o otros usuarios u objetos cuando:

  • Sea el propietario.
  • Tenga un privilegio concedido con la opción WITH GRANT OPTION.
  • Tenga privilegios adquiridos con un rol con la opción WITH ADMIN OPTION.

Cuidado con los privilegios concedidos doblemente , como por ejemplo por dos usuarios diferentes. Si uno revoca el privilegio y el otro no, el usuario sigue teniendo el privilegio.

Procedimientos almacenados

Con respecto a los procedimientos almacenados la sintaxis de GRANT se muestra:

GRANT EXECUTE ON PROCEDURE procname TO {<object> | <userlist>}

<object> = {PROCEDURE procname

| TRIGGER trigname

| VIEW viewname

| PUBLIC}

[, <object> …]

 

<userlist> = {[USER] username

| rolename

| UNIX_user}

[, <userlist> …]

[WITH GRANT OPTION]

Si usamos la cláusula PUBLIC, no podemos asignar nuevos privilegios a usuarios ni a procedimientos.

GRANT EXECUTE ON PROCEDURE FUND_BALANCE TO NKOMO, SUSAN, PROCEDURE ACCT_MAINT, MONEY_TRANSFER;

Vistas.

Para un usuario una vista es como una tabla, pero, no son lo mismo, las vistas generadas a partir de GROUP BY o JOIN no son actualizables, las generadas a partir de una sola tabla si lo son. Por lo tanto los privilegios de UPDATE, DELETE o INSERT pueden ser asignados dependiendo del tipo de vista que sea, ademas, el privilegio REFERENCES no puede ser asignado a ningún tipo de vista.

La sintaxis es la siguiente:

GRANT <privileges> ON viewname

TO {<object> | <userlist> | GROUP UNIX_group};

<privileges> = ALL [PRIVILEGES] | <privilege_list>

<privilege_list> = {SELECT

| DELETE

| INSERT

| UPDATE [(col [, col …])]}

[, <privilege_list> …]

 

<object> = {PROCEDURE procname

| TRIGGER trigname

| VIEW viewname

| PUBLIC}

[, <object> …]

 

<userlist> = {[USER] username

| rolename

| UNIX_user}

[, <userlist> …]

[WITH GRANT OPTION]

 

REVOKE: Retirar privilegios concedidos.

Usaremos la sentencia REVOKE  para eliminar privilegios que fueron asignados con GRANT.

Necesitamos como mínimo los siguientes parámetros:

  • Un privilegio a eliminar.
  • La tabla o vista a la que se aplicaba el privilegio.
  • El nombre del objeto que tiene el privilegio actual a eliminar.

La sintaxis general es:

REVOKE <privileges> ON [TABLE] {tablename | viewname}

FROM {<object> | <userlist> | GROUP UNIX_group};

<privileges> = ALL [PRIVILEGES] | <privilege_list>

<privilege_list> = {SELECT

| DELETE

| INSERT

| UPDATE [(col [, col …])]

| REFERENCES [(col [, col …])]}

[, <privilege_list> …]

<object> = {PROCEDURE procname

| TRIGGER trigname

| VIEW viewname

| PUBLIC}

[, <object> …]

<userlist> = [USER] username [, [USER] username …]

 

  • Los privilegios solo pueden ser revocados por el usuario que los garantizó.
  • Otros privilegios asignados por otros usuarios no son afectados.
  • Quitar un privilegio a un usuario que daba privilegios (de segunda mano), revoca los privilegios dados por este primero.
  • Privilegios dados con PUBLIC solo se eliminan con PUBLIC.

Varios ejemplos:

REVOKE SELECT ON DEPARTMENTS FROM SUSAN;

REVOKE UPDATE ON ACCOUNTS FROM PROCEDURE MONEY_TRANSER;

REVOKE EXECUTE ON PROCEDURE MONEY_TRANSER FROM PROCEDURE ACCT_MAINT;

REVOKE INSERT, DELETE ON ACCOUNTS FROM PROCEDURE MONEY_TRANSFER;

 

Podemos usar la cláusula ALL para revocar todos los privilegios aunque el usuario no los tenga todos, pero ALL nunca elimina el de EXECUTE.

REVOKE INSERT, UPDATE ON DEPARTMENTS FROM LI;

REVOKE INSERT, UPDATE ON DEPARTMENTS FROM FRANCIS, BEATRICE, HELGA;

REVOKE ALL ON DEPARTMENTS FROM SUSAN;

Para especificar varios usuarios podemos usar las comas.

En el caso de los roles :

Para eliminar privilegios de un rol:

REVOKE privileges ON table FROM rolenamelist;

Para revocar un rol asignado a un usuario:

REVOKE role_granted FROM {PUBLIC | role_grantee_list};

Si usamos DROP ROLE todos los privilegios que fueron asignados al rol desaparecen.

Con respecto a los privilegios de ejecución (EXECUTE). La sintaxis es la siguiente:

REVOKE EXECUTE ON PROCEDURE procname FROM {<object> | <userlist>}

<object> = {PROCEDURE procname

| TRIGGER trigname

| VIEW viewname

| PUBLIC}

[, <object> …]

 

<userlist> = [USER] username [, [USER] username …]

Ejemplo:

REVOKE INSERT, UPDATE ON ACCOUNTS FROM PROCEDURE MONEY_TRANSFER,

ACCT_MAINT TRIGGER SHOW_USER;

Para eliminar el privilegio de conceder privilegios a otros usuarios y a la vez eliminar los privilegios concedidos por ese método,debemos usar la siguiente sintaxis:

REVOKE GRANT OPTION FOR privilege [, privilege …] ON table

FROM user;

Las vistas también ayudan a la seguridad.

En conjunción con el uso de GRANT Y REVOKE, podemos usar vistas para restringir el acceso a los datos. Una vista es un subconjunto de columnas y filas de una o más tablas, esta situación provee ya una cierta seguridad de acceso.

Por ejemplo, queremos que todo el mundo vea los datos sobre empleados, pero hay cierta información (el salario) que consideramos confidencial. Para que todo el mundo tenga acceso al resto de las columnas creamos una vista excluyendo el salario, y a esa vista le damos permiso a todos los usuarios.  Los usuarios podrán acceder a la información de los empleados pero solo el creador de la tabla empleados y el SYSDBA tendrán acceso al salario.

CREATE VIEW EMPDATA AS

SELECT LAST_NAME, FIRST_NAME, DEPARTMENT, JOB, PHONE

FROM EMPLOYEES;

 

GRANT SELECT FROM EMPDATA TO PUBLIC;


Autor: Antonio Lopez Atienza


Tags: ,
Posted in Interbase | No Comments »

Leave a Comment

 

RSS
MCC D5E