Le pseudo-rôle public reçoit le privilège USAGE sur le schéma z_plume qui regroupe tous les objets de PlumePg.
Le privilège SELECT est conféré au pseudo-rôle public sur toutes les tables et vues de l'extension.
Sur la table z_plume.stamp_timestamp, public reçoit également INSERT, UPDATE et DELETE, un contrôle d'accès plus fin étant réalisé par le déclencheur stamp_timestamp_access_control.
Aucun rôle ne reçoit de droits spécifiques sur les séquences de PlumePg.
L'idée générale est que tout utilisateur puisse accéder en lecture à toutes les données, mais que - hormis pour z_plume.stamp_timestamp - l'administrateur soit contraint de donner explicitement des droits supplémentaires lorsqu'il juge pertinent d'autoriser des rôles autres que le propriétaire des tables à modifier leur contenu.
Conférer aussi le privilège SELECT à public mériterait toutefois d'être considéré, car il est notamment nécessaire pour qu'un rôle autre que le propriétaire de l'extension puisse réaliser des sauvegardes de la base.
Par ailleurs, le fait que seul le propriétaire de l'extension ait nativement le droit de modifier les données des modèles peut devenir problématique si l'administrateur du serveur n'a pas accès au rôle super-utilisateur propriétaire de l'extension. Utiliser @extowner@ pour donner des droits au rôle qui a effectivement lancé la commande d'activation de l'extension pourrait notamment être envisagé. Il pourrait même être fait propriétaire des objets de l'extension.
À l'heure actuelle :
publicreçoit le privilègeUSAGEsur le schémaz_plumequi regroupe tous les objets de PlumePg.SELECTest conféré au pseudo-rôlepublicsur toutes les tables et vues de l'extension.z_plume.stamp_timestamp,publicreçoit égalementINSERT,UPDATEetDELETE, un contrôle d'accès plus fin étant réalisé par le déclencheurstamp_timestamp_access_control.L'idée générale est que tout utilisateur puisse accéder en lecture à toutes les données, mais que - hormis pour
z_plume.stamp_timestamp- l'administrateur soit contraint de donner explicitement des droits supplémentaires lorsqu'il juge pertinent d'autoriser des rôles autres que le propriétaire des tables à modifier leur contenu.Conférer aussi le privilège
SELECTàpublicmériterait toutefois d'être considéré, car il est notamment nécessaire pour qu'un rôle autre que le propriétaire de l'extension puisse réaliser des sauvegardes de la base.Par ailleurs, le fait que seul le propriétaire de l'extension ait nativement le droit de modifier les données des modèles peut devenir problématique si l'administrateur du serveur n'a pas accès au rôle super-utilisateur propriétaire de l'extension. Utiliser
@extowner@pour donner des droits au rôle qui a effectivement lancé la commande d'activation de l'extension pourrait notamment être envisagé. Il pourrait même être fait propriétaire des objets de l'extension.