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; |
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.
Atenci�n | |
---|---|
GRANT ALL actualmente incluye permisos RULE. Esto permite al usuario autorizado borrar la regla, hacer los cambios y reinstalarla. Pienso que esto deber�a ser cambiado r�pidamente. |