Principes

Sommaire
  1. Maintien de la cohérence des propriétaires
  2. Trois profils de droits
  3. Table de gestion et vue utilisateur

En matière d'attribution de droits, le mécanisme par défaut de PostgreSQL n’est généralement pas conforme à un comportement simplifié souhaité par les services. En effet, il implique des actions pour les créateurs d’objets s’ils souhaitent que d’autres utilisateurs aient accès à leurs objets. Lorsque cette attribution explicite de droits est réalisée à la main, elle peut rapidement devenir fastidieuse et source d’erreurs.

Avec ASGARD des droits standards sont appliqués automatiquement au moment de la création des objets dans les schémas et le propriétaire est ré-affecté de manière à rester cohérent avec le propriétaire du schéma.

Maintien de la cohérence des propriétaires⚓

Le propriétaire d’un schéma est le propriétaire de tous les objets qu’il contient.

Remarque

Cette règle est « imposée » au sens où son respect conditionne le bon fonctionnement du système, mais surtout parce qu’ASGARD s’assure qu’elle ne soit jamais enfreinte en procédant dès que besoin à des réaffectations automatiques de propriété. L’utilisateur n’a ainsi jamais à s’en préoccuper. Comme discuté par la suite, cette règle ne concerne cependant que les schémas référencés[1] par ASGARD et rien n’oblige à ce que tous les schémas le soient.

Une conséquence directe de cette règle est qu'il ne sert à rien de donner à un rôle non membre du propriétaire d'un schéma le privilège CREATE sur ce schéma. Puisqu'il n'est pas membre du propriétaire, il ne sera pas possible de réaffecter au propriétaire les objets qu'il crée, et par conséquent toutes ses commandes de création d'objets se solderont par des erreurs. Dans le contexte d'Asgard, la seule méthode pour permettre à un rôle de créer des objets dans un schéma est d'en faire le propriétaire de ce schéma ou de le rendre membre dudit propriétaire.

Complément⚓

Il est fortement déconseillé d'y recourir, néanmoins la partie Désactiver ASGARD ? évoque plusieurs méthodes pour contourner la mise en cohérence automatique des propriétaires.

Trois profils de droits⚓

L’idée centrale d'ASGARD est de définir trois profils de droits – producteur du schéma, éditeur du schéma et lecteur du schéma.

  • Les lecteurs ont accès en lecture seule aux données du schéma. En pratique, ils ont les privilèges USAGE sur les schémas et SELECT sur les tables (y compris vues, vues matérialisées, tables étrangères et tables partitionnées) et les séquences.

  • Les éditeurs ont tous les droits des lecteurs, auxquels s’ajoutent les droits qui permettent la modification des données : INSERT, UPDATE et DELETE sur les tables ou assimilés et USAGE sur les séquences.

  • Les producteurs sont propriétaires des schémas et reçoivent donc automatiquement la propriété de tous les objets qui y sont créés. À ce titre (cf. Prérogatives du propriétaire), ils ont tous les droits sur les schémas et les objets qu’ils contiennent. En plus de la visualisation et l’édition des données, les membres du groupe producteur peuvent créer des objets dans le schéma, les supprimer, modifier leur définition ou encore attribuer ou révoquer des droits sur ces objets pour les autres rôles de groupe.

Pour chaque schéma, il est possible de pré-désigner au maximum un rôle de groupe par fonction.

Avec ASGARD, tout schéma a un rôle producteur (propriétaire) et au plus un rôle éditeur et un rôle lecteur.

Remarque

Il demeure possible de conférer ou révoquer manuellement des privilèges, y compris lorsqu’ils avaient été alloués par ASGARD. Ces modifications ne seront jamais remises en cause par l’extension.

Table de gestion et vue utilisateur⚓

La liste des schémas et des rôles associés est stockée dans la table gestion_schema du schéma z_asgard_admin, dite « table de gestion ». Les utilisateurs la consultent et l’alimentent via la vue gestion_schema_usr du schéma z_asgard, dite « vue utilisateur », qui est ainsi l’objet central de la gestion des droits. Cette vue est présentée en détails dans la partie Vue utilisateur.

Exemple

Extrait de la vue gestion_schema_usr :

Dans cet exemple, le schéma c_bibliotheque a pour éditeur[2] le rôle de groupe[3] g_assistant. Les membres de g_assistant pourront ainsi modifier les données contenues dans les tables du schéma c_bibliotheque, quel que soit le rôle de connexion[4] de l’utilisateur qui, en pratique, aura procédé à la création de l’objet.