Pour une extension censée simplifier la gestion des droits, Asgard est paradoxalement assez contraignant quand il s'agit de ses propres objets. Il pose aujourd'hui les conditions suivantes :
Les rôles producteurs des schémas doivent être membres de g_consult ou du lecteur du schéma z_asgard pour pouvoir créer ou modifier des objets dans leurs schémas^ref-1.
Les rôles habilités à gérer les schémas - privilège CREATE sur la base - doivent être membres de l'éditeur du schéma z_asgard pour pouvoir effectivement faire usage de ce droit^ref-2. La case à cocher Gestion des schémas simplifie légèrement les choses côté AsgardManager, mais ce système reste assez peu lisible.
Les rôles des utilisateurs d'AsgardMenu doivent être membres de g_consult ou du lecteur du schéma z_asgard^ref-3.
Ces règles n'auraient plus lieu d'être si nous nous autorisions à donner au pseudo-rôle public un accès en lecture aux vues du schéma z_asgard et des privilèges d'édition sur les vues z_asgard.gestion_schema_usr et z_asgard.gestion_schema_etr.
GRANT USAGE ON SCHEMA z_asgard TO public ;
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE z_asgard.gestion_schema_usr TO public ;
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE z_asgard.gestion_schema_etr TO public ;
GRANT SELECT ON TABLE z_asgard.asgardmenu_metadata TO public ;
GRANT SELECT ON TABLE z_asgard.asgardmanager_metadata TO public ;
GRANT SELECT ON TABLE z_asgard.gestion_schema_read_only TO public ;
Ceci ne nécessite même pas d'ajouter des contrôles par ailleurs, car - le lecteur et l'éditeur de z_asgard n'étant pas connus a priori - tout est déjà en place. Les privilèges d'édition sur les vues z_asgard.gestion_schema_usr et z_asgard.gestion_schema_etr sont notamment contre-balancés par le fait que ces vues ne montrent à un rôle que les schémas sur lesquels il est habilité à agir^ref-1 (restriction pour UPDATE et DELETE) et par le déclencheur asgard_on_modify_gestion_schema_before sur la table z_asgard_admin.gestion_schema. Le tout premier test réalisé par la fonction z_asgard_admin.asgard_on_modify_gestion_schema_before() appelée par ce déclencheur consiste en effet à interdire l'ajout d'enregistrements par un rôle qui n'aurait pas le privilège CREATE sur la base (restriction sur INSERT, les modifications des vues z_asgard.gestion_schema_usr et z_asgard.gestion_schema_etr étant transférées sur z_asgard_admin.gestion_schema).
Outre l'ajout des permissions susmentionnées et beaucoup de simplifications dans la documentation, les seules modifications à faire dans l'extension PostgreSQL seraient :
la suppression des privilèges accordés à g_consult sur les objets d'Asgard, qui seraient redondants avec ceux de public.
l'adaptation des commandes de rétablissement des privilèges requis sur les objets d'Asgard.
la suppression ou l'adaptation des vérifications de permissions sur les objets d'Asgard réalisées par les fonctions des déclencheurs d'évènements. Si ces tests ne sont pas supprimés purement et simplement, leurs messages d'erreur devront être réécrits.
Côté AsgardManager, la case à cocher Gestions des schémas ne servirait plus qu'à conférer CREATE sur la base.
Cette évolution permettrait aussi de recentrer g_consult sur sa fonction d'accès aux données, tandis que public sera plus pertinent pour conférer un accès universel aux objets techniques qui le justifient. Le cumul de ces deux fonctions par g_consult pouvait également poser problème dans quelques cas particuliers^ref-4.
Pour une extension censée simplifier la gestion des droits, Asgard est paradoxalement assez contraignant quand il s'agit de ses propres objets. Il pose aujourd'hui les conditions suivantes :
g_consultou du lecteur du schémaz_asgardpour pouvoir créer ou modifier des objets dans leurs schémas^ref-1.CREATEsur la base - doivent être membres de l'éditeur du schémaz_asgardpour pouvoir effectivement faire usage de ce droit^ref-2. La case à cocher Gestion des schémas simplifie légèrement les choses côté AsgardManager, mais ce système reste assez peu lisible.g_consultou du lecteur du schémaz_asgard^ref-3.Ces règles n'auraient plus lieu d'être si nous nous autorisions à donner au pseudo-rôle
publicun accès en lecture aux vues du schémaz_asgardet des privilèges d'édition sur les vuesz_asgard.gestion_schema_usretz_asgard.gestion_schema_etr.Ceci ne nécessite même pas d'ajouter des contrôles par ailleurs, car - le lecteur et l'éditeur de
z_asgardn'étant pas connus a priori - tout est déjà en place. Les privilèges d'édition sur les vuesz_asgard.gestion_schema_usretz_asgard.gestion_schema_etrsont notamment contre-balancés par le fait que ces vues ne montrent à un rôle que les schémas sur lesquels il est habilité à agir^ref-1 (restriction pourUPDATEetDELETE) et par le déclencheurasgard_on_modify_gestion_schema_beforesur la tablez_asgard_admin.gestion_schema. Le tout premier test réalisé par la fonctionz_asgard_admin.asgard_on_modify_gestion_schema_before()appelée par ce déclencheur consiste en effet à interdire l'ajout d'enregistrements par un rôle qui n'aurait pas le privilègeCREATEsur la base (restriction surINSERT, les modifications des vuesz_asgard.gestion_schema_usretz_asgard.gestion_schema_etrétant transférées surz_asgard_admin.gestion_schema).Outre l'ajout des permissions susmentionnées et beaucoup de simplifications dans la documentation, les seules modifications à faire dans l'extension PostgreSQL seraient :
g_consultsur les objets d'Asgard, qui seraient redondants avec ceux depublic.Côté AsgardManager, la case à cocher Gestions des schémas ne servirait plus qu'à conférer
CREATEsur la base.Cette évolution permettrait aussi de recentrer
g_consultsur sa fonction d'accès aux données, tandis quepublicsera plus pertinent pour conférer un accès universel aux objets techniques qui le justifient. Le cumul de ces deux fonctions parg_consultpouvait également poser problème dans quelques cas particuliers^ref-4.