33.4. R�gles et droits

� cause de la r��criture des requ�tes par le syst�me de r�gles de PostgreSQL, d'autres tables/vues que celles utilis�es dans la requ�te originale pourraient �tre acc�d�es. Lorsque des r�gles de mise � jour sont utilis�es, ceci peut inclure des droits d'�criture sur les tables.

Les r�gles de r��criture n'ont pas de propri�taire s�par�. Le propri�taire d'une relation (table ou vue) est automatiquement le propri�taire des r�gles de r��criture qui lui sont d�finies. Le syst�me de r�gles de PostgreSQL modifie le comportement du syst�me de contr�le d'acc�s par d�faut. Les relations qui sont utilis�es � cause des r�gles se voient v�rifier avec les droits du propri�taire de la r�gle, et non avec ceux de l'utilisateur appelant cette r�gle. Ceci signifie qu'un utilisateur a seulement besoin des droits requis pour les tables/vues qu'il nomme explicitement dans ses requ�tes.

Par exemple : un utilisateur a une liste de num�ros de t�l�phone dont certains sont priv�s, les autres �tant d'int�r�t pour la secr�taire du bureau. Il peut construire de cette fa�on :

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

Personne sauf lui (et les superutilisateurs de la base de donn�es) ne peut acc�der � la table phone_data. Mais, � cause du GRANT, la secr�taire peut lancer un SELECT sur la vue phone_number. Le syst�me de r�gles r��crira le SELECT sur phone_number en un SELECT sur phone_data et ajoutera la qualification que seules les entr�es non priv�es (donc o� private est faux) sont d�sir�es. Comme l'utilisateur est le propri�taire de phone_number et du coup le propri�taire de la r�gle, le droit de lecture de phone_data est maintenant v�rifi� avec ses propres privil�ges et la requ�te est autoris�e. La v�rification de l'acc�s � phone_number est aussi r�alis�e mais ceci est fait avec l'utilisateur appelant, donc personne sauf l'utilisateur et la secr�taire ne peut l'utiliser.

Les droits sont v�rifi�s r�gle par r�gle. Donc, la secr�taire est actuellement la seule � pouvoir voir les num�ros de t�l�phone publiques. Mais la secr�taire peut configurer une autre vue et autoriser l'acc�s au public. Du coup, tout le monde peut voir les donn�es de phone_number via la vue de la secr�taire. Ce que la secr�taire ne peut pas faire est de cr�er une vue qui acc�de directement � phone_data (en fait, elle le peut mais cela ne fonctionnera pas car tous les acc�s seront refus�s lors de la v�rification des droits). D�s que l'utilisateur s'en rendra compte, du fait que la secr�taire a ouvert la vue phone_number � tout le monde, il peut r�voquer son acc�s. Imm�diatement, tous les acc�s de la vue de la secr�taire �choueront.

Il pourrait �tre dit que cette v�rification r�gle par r�gle est une br�che de s�curit� mais ce n'est pas le cas. Si cela ne fonctionne pas de cette fa�on, la secr�taire pourrait copier une table avec les m�mes colonnes que phone_number et y copier les donn�es une fois par jour. Du coup, ce sont ces propres donn�es et elle peut accorder l'acc�s � tout le monde si elle le souhaite. Une commande GRANT signifie <<�J'ai confiance en vous�>>. Si quelqu'un en qui vous avez confiance se comporte ainsi, il est temps d'y r�fl�chir et d'utiliser REVOKE.

Ce m�canisme fonctionne aussi pour les r�gles de mise � jour. Dans les exemples de la section pr�c�dente, le propri�taire des tables de la base de donn�es d'exemple pourrait accorder les droits SELECT, INSERT, UPDATE et DELETE sur la vue lacet � quelqu'un d'autre mais seulement SELECT sur lacet_log. L'action de la r�gle pourrait �crire des entr�es de trace qui seraient toujours ex�cut�es avec succ�s et que l'autre utilisateur pourrait voir. Mais il ne peut pas cr�er d'entr�es fausses, pas plus qu'il ne peut manipuler ou supprimer celles qui existent.