Reglas y Permisos

Debido a la reescritura de las queries por el sistema de reglas de Postgre, se han accedido a otras tablas/vistas diferentes de las de la query original. Utilizando las reglas de update, esto puede incluir acceso en escritura a tablas.

Las reglas de reescritura no tienen un propietario diferenciado. El propietario de una relación (tabla o vista) es automáticamente el propietario de las reglas de reescritura definidas para ella. El sistema de reglas de Postgres cambia el comportamiento del sistema de control de acceso de defecto. Las relaciones que se utilizan debido a las reglas son comprobadas durante la reescritura contralos permisos del propietario de la relación, contra la que la regla se ha definido. Esto hace que el usuario no necesite sólo permisos para las tablas/vistas a las que él hace referencia en sus queries.

Por ejemplo: Un usuario tiene una lista de números de teléfono en la que algunos son privados y otros son de interés para la secretaria en la oficina. Él puede construir lo siguiente:

    CREATE TABLE phone_data (person text, phone text, private bool);
    CREATE VIEW phone_number AS
        SELECT person, phone FROM phone_data WHERE NOT private;
    GRANT SELECT ON phone_number TO secretary;

Nadie excepto él, y el superusuario de la base de datos, pueden acceder a la tabla phone_data. Pero debido a la GRANT, la secretaria puede SELECT a través de la vista phone_numbre. El sistema de reglas reescribirá la SELECT de phone_numbre en una SELECT de phone_data y añade la cualificación de que sólo se buscan las entradas cuyo "privado" sea falso. Una vez que el usuario sea el propietario de phone_numbre, la lectura accede a phone_data se comprueba contra sus permisos, y la query se considera autorizada. La comprobación para acceder a phone_number se realiza entonces, de modo que nadie más que la secretaria pueda utilizarlo.

Los permisos son comprobados regla a regla. De modo que la secretaria es ahora la única que puede ver los números de teléfono públicos. Pero la secretaria puede crear otra vista y autorizar el acceso a ella al público. Entonces, cualquiera puede ver los datos de phone_numbre a través de la vista de la secretaria. Lo que la secretaria no puede hacer es crear una vista que acceda directamente a phone_data (realmente si puede, pero no trabajará, puesto que cada acceso abortará la transacción durante la comprobación de los permisos). Y tan pronto como el usuario tenga noticia de que la secretaria ha abierto su vista a phone_numbre, el puede REVOKE su acceso. Inmediatamente después, cualquier acceso a la vista de las secretarias fallará.

Alguien podría pensar que este chequeo regla a regla es un agujero de seguridad, pero de hecho no lo es. Si esto no trabajase, la secretaria podría generar una tabla con las mismas columnas de phone_number y copiar los datos aquí todos los días. En este caso serían ya sus propios datos, y podría autorizar el acceso a cualquiera que ella quisiera. Un GRANT quiere decir "Yo Confío en Tí". Si alguien en quien confiamos hace lo anterior, es el momento de volver sobre nuestros pasos, y hacer el REVOKE.

Este mecanismo también trabaja para reglas de update. En el ejemplo de la sección previa, el propietario de las tablas de la base de datos de Al (suponiendo que no fuera el mismo Al) podría haber autorizado (GRANT) SELECT, INSERT, UPDATE o DELETE a la vista shoelace a Al. Pero sólo SELECT en shoelace_log. La acción de la regla de escribir entradas del log deberá ser ejecutada con exito, y Al podría ver las entradas del log, pero el no puede crear nuevas entradas, ni podría manipular ni remover las existentes.