producteur (champ de la table de gestion)
Rôle désigné comme producteur pour le schéma (propriétaire du schéma et de tout son contenu). Obligatoire.
producteur est une chaîne de caractères.
Il désigne le rôle de groupe du profil « producteur[1] » pour le schéma, c’est-à-dire le rôle qui en est le propriétaire et a tous les droits sur le schéma et les futurs objets qu’il contiendra. Cf. Trois profils de droits pour la description complète des prérogatives du producteur.
Ce champ ne peut être NULL. Il n’a pas de valeur par défaut au sens de PostgreSQL, cependant les mécanismes internes d’ASGARD font que le rôle g_admin sera utilisé en l’absence d’autre valeur.
producteur est pré-renseigné avec g_admin[3] pour les schémas de la nomenclature nationale[2].
Si le rôle saisi dans ce champ n’existe pas et que le champ creation[4] vaut True, un rôle du nom renseigné sera automatique créé – sous réserve toutefois que l’opérateur soit habilité à créer des rôles (cf. Déléguer la gestion des droits).
ASGARD impose aux champs producteur, editeur et lecteur de prendre des valeurs différentes (ou NULL pour les deux derniers).
Réglementaire : Règle imposée par ASGARD⚓
Le producteur ne peut pas être un rôle de connexion[5], sauf s’il s’agit d’un super-utilisateur[6].
Cette règle découle du principe des rôles de groupe, sans lequel il devient rapidement difficile pour l'administrateur de se repérer dans les droits alloués. Elle permet aussi à g_admin et ses membres de garder le contrôle de l'ensemble des objets de la base (sauf ceux qui appartiennent aux super-utilisateurs), comme il se doit pour un administrateur, sans pour autant être rendus membres de rôles de connexion qui, par principe, se veulent individuels.
Si son intérêt à long terme est indéniable, elle nécessite toutefois une adaptation des pratiques, en particulier lors de la création de nouveaux schémas ou lors de l'import de schémas.
Exemple :
Si le rôle de connexion jon.sow membre de g_admin tente de créer un nouveau schéma sans spécifier de propriétaire dans sa commande :
CREATE SCHEMA c_bibliotheque ;
... PostgreSQL considère que c'est le rôle de connexion jon.snow lui-même qui doit être propriétaire – et donc producteur – du schéma, et ASGARD renvoie par conséquent une erreur :
ERREUR: ECS0 > TA0 > TA3. Opération interdite (schéma c_bibliotheque). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.
Il lui faut spécifier dans sa commande de création le rôle de groupe (dont il doit être membre) qui deviendra le producteur du schéma. En l'occurrence, jon.snow pourra désigner g_admin :
CREATE SCHEMA c_bibliotheque AUTHORIZATION g_admin ;
Après modification du producteur (pour un schéma existant) :
L’ancien producteur n’aura plus aucun privilège direct sur le schéma et les objets qu’il contient. Le cas échéant, il bénéficie toujours des privilèges conférés à tous les utilisateurs via le pseudo-rôle public et des privilèges hérités des rôles dont il est membre.
Le nouveau producteur sera propriétaire du schéma et de tous ses objets, et il aura sur eux très précisément les privilèges qu’avait auparavant l’ancien.
Concrètement, cela signifie que si un privilège avait fait l’objet d’une révocation manuelle pour l’ancien producteur (par exemple pour éviter une modification accidentelle), il restera révoqué pour le nouveau. En tant que propriétaire des objets, celui-ci pourra bien entendu rétablir son privilège manquant s’il le souhaite.
Ce principe de transfert des privilèges correspond au fonctionnement naturel de PostgreSQL en cas de changement de propriétaire. ASGARD conserve ce mécanisme pour les producteurs et le reproduit pour les éditeurs[7] et lecteurs[8].
Dans le contexte d’ASGARD, lancer une commande de modification du propriétaire d’un schéma revient à désigner un nouveau producteur. Sur ce sujet, cf. Modifier le propriétaire d'un schéma.
Remarque :
Au contraire de nom_schema, le champ producteur n’est pas immédiatement mis à jour lorsqu’un rôle est renommé. Dans la mesure où ASGARD conserve également l’identifiant système du rôle producteur de tous les schémas créés, il saura néanmoins toujours de quel rôle il était question. Pour plus de précisions sur les modalités de rafraîchissement des noms des rôles dans la table de gestion, cf. Modification des rôles.