Closed alhyss closed 2 years ago
En complément : avec certains objets (les déclencheurs, les fonctions, les vues matérialisées...), il existe une commande ALTER ... DEPENDS ON EXTENSION ...
qui permet de rattacher explicitement l'objet à une extension afin qu'il soit automatiquement supprimé lorsqu'elle l'est. Les politiques de sécurité ne sont toutefois pas concernées.
Après quelques fouilles...
Cette limitation est documentée (https://www.postgresql.org/docs/14/extend-extensions.html) : PostgreSQL does not currently support extension scripts issuing CREATE POLICY or SECURITY LABEL statements. These are expected to be set after the extension has been created. All RLS policies and security labels on extension objects will be included in dumps created by pg_dump.
Ticket de novembre 2021 sur le sujet : https://www.postgresql.org/message-id/CAANoKdbO=y0FT9fSzP24-kMf_A5y9xyujwJQk3=HgDynZYMAzQ@mail.gmail.com. Il explique bien le problème mais n'a jamais eu de réponse.
Une solution serait de définir un déclencheur sur z_plume.stamp_timestamp
qui de provoque une erreur si le rôle qui exécute la commande n'est ni le propriétaire de stamp_timestamp
ni le propriétaire de la table dont l'OID est OLD.relid
/ NEW.relid
. Fonctionnellement, c'est équivalent, même si c'est moins propre, vraisemblablement moins performant et potentiellement moins sûr.
Je vais partir là-dessus pour le moment afin d'éviter l'erreur... et reviendrait aux politiques de sécurité le jour où PostgreSQL les prendra correctement en charge pour les extensions.
Pour mémoire :
ALTER TABLE z_plume.stamp_timestamp ENABLE ROW LEVEL SECURITY ;
-- Policy: timestamp_public_select
CREATE POLICY timestamp_public_select ON z_plume.stamp_timestamp
FOR SELECT USING (True) ;
-- Policy: timestamp_owner_insert
CREATE POLICY timestamp_owner_insert ON z_plume.stamp_timestamp
FOR INSERT WITH CHECK (z_plume.is_relowner(relid)) ;
-- Policy: timestamp_owner_update
CREATE POLICY timestamp_owner_update ON z_plume.stamp_timestamp
FOR UPDATE USING (z_plume.is_relowner(relid))
WITH CHECK (z_plume.is_relowner(relid)) ;
-- Policy: timestamp_owner_delete
CREATE POLICY timestamp_owner_delete ON z_plume.stamp_timestamp
FOR DELETE USING (z_plume.is_relowner(relid)) ;
C'est fait. public
reçoit initialement SELECT
, INSERT
, UPDATE
et DELETE
sur stamp_timestamp
. Le déclencheur stamp_timestamp_access_control
veille à ce que seul le propriétaire de stamp_timestamp
ou le propriétaire de la table concernée par un enregistrement puisse agir sur celui-ci.
Constaté sous PostgreSQL 14.2, comportement à confirmer avec les autres versions.
La restauration d'une base sur laquelle était installée PlumePg donne lieu à des erreurs sur la recréation des quatre politiques de sécurité niveau ligne définies sur la table
z_plume.stamp_timestamp
:timestamp_public_select
,timestamp_owner_insert
,timestamp_owner_update
ettimestamp_owner_delete
. Elles sont en effet créées deux fois : une fois par le script de création de l'extension (commandeCREATE EXTENSION plume_pg
du script de restauration), puis une fois par des commandesCREATE POLICY
explicites dans le script de restauration.Exemple d'erreur :
Ces erreurs sont sans conséquence, puisque les politiques de sécurité ont bien été créées et qu'il n'y aurait pas lieu de reproduire des modifications manuelles réalisées a posteriori. Mais il ne paraît pas normal que le script de restauration comprenne les commandes
CREATE POLICY
en question. Du point de vue des dépendances, elles fonctionnent comme les déclencheurs : elles ne sont pas marquées comme directement dépendantes de l'extension (au contraire du schéma, des tables, des types, etc.), mais elles ont une dépendance de typea
/DEPENDENCY_AUTO
vis-à-vis de leur relation, qui elle-même a une dépendance de typee
/DEPENDENCY_EXTENSION
vis-à-vis de l'extension. On pourrait donc s'attendre à ce que, comme les déclencheurs,pg_dump
sache les identifier comme objets à ne pas recréer. En pratique et sans aucune certitude, la différence de traitement vient peut-être du fait que les politiques de sécurité ont aussi des dépendances de typesn
/DEPENDENCY_NORMAL
sur les colonnes qui apparaissent dans les conditions de leurs clausesUSING
etWITH CHECK
... mais ça n'est pas une bonne raison.z_plume.stamp_timestamp
n'est pas une table de configuration de l'extension, il faudrait voir si elles réagissent de la même façon.J'ouvre une issue pour mémoire, mais je ne vois pas comment éviter ces erreurs. Comme c'est surtout le comportement de
pg_dump
qui me semble manquer de cohérence, je vais certainement faire un ticket d'anomalie et voir ce qui en sort.Bien que ceci ne provoque pas d'erreur, il est également assez surprenant que le script de restauration contienne une commande
ALTER TABLE z_plume.stamp_timestamp ENABLE ROW LEVEL SECURITY;
, alors qu'il n'y a pas de commandeENABLE
/DISABLE
pour les déclencheurs et déclencheurs sur évènement, par exemple. Il n'est pas très intuitif que les déclencheurs soient recréés dans l'état défini par l'extension, comme le sont plus généralement tous les objets créés par l'extension hors contenu des tables identifiées comme tables de configuration de l'extension, tandis qu'une désactivation manuelle de la politique de sécurité serait préservée.