PostgreSQL 16 introduit des changements significatifs concernant la gestion des droits, avec notamment une restriction des prérogatives attachées à l'attribut CREATEROLE qui ne permet plus de lancer des commandes GRANT pour attribuer la permission à n'importe quel rôle sur n'importe quel autre (non super-utilisateur). Désormais, il est nécessaire d'être membre avec l'option ADMIN du rôle dont on veut rendre l'autre membre. Il faut également être membre d'un rôle avec l'option ADMIN pour pouvoir le modifier ou le supprimer, en plus d'avoir l'attribut CREATEROLE. C'est par défaut le cas pour tous les rôles que le rôle a créés, mais pas les autres.
Ces changements font qu'Asgard 1.4.0 n'est pas compatible avec PostgreSQL 16. En particulier, les mécanismes grâce auxquels g_admin était rendu membre de tous les rôles désignés comme producteurs de schémas ne fonctionnent plus, au moins pour les rôles producteurs qui n'ont pas été créés par g_admin.
Plus généralement, cette évolution a pour principe d'assurer qu'aucun rôle non super-utilisateur ne puisse maîtriser nativement tous les autres rôles non super-utilisateurs sauf à y être explicitement autorisé pour chacun d'eux. Quels que soient les correctifs mis en œuvre, le contrôle de g_admin sur la base s'en trouvera nécessairement diminué si d'autres rôles (y compris des rôles de connexion) sont amenés à créer des rôles, sauf à ce que les administrateurs pensent à ajouter ADMIN g_admin à toutes leurs commandes de création de rôles... Pour ne rien arranger, il était jusqu'ici recommandé dans la documentation d'Asgard de conférer l'attribut CREATEROLE aux rôles de connexion des administrateurs pour leur éviter d'avoir à lancer un SET ROLE g_admin avant de pouvoir créer, modifier ou supprimer un rôle. Il est donc naturel que plusieurs rôles soient amenés à gérer les rôles dans le contexte actuel.
Deux niveaux d'intervention sont donc à prévoir :
Corriger les erreurs de manière à assurer également la rétrocompatibilité avec les versions antérieures.
Revoir globalement le système (mécanismes automatisés et recommandations) pour permettre à l'administrateur de conserver un contrôle aussi large que possible sur sa base, tout en mettant clairement en évidence les schémas sur lesquels il n'a pas la main.
PostgreSQL 16 introduit des changements significatifs concernant la gestion des droits, avec notamment une restriction des prérogatives attachées à l'attribut
CREATEROLEqui ne permet plus de lancer des commandesGRANTpour attribuer la permission à n'importe quel rôle sur n'importe quel autre (non super-utilisateur). Désormais, il est nécessaire d'être membre avec l'optionADMINdu rôle dont on veut rendre l'autre membre. Il faut également être membre d'un rôle avec l'optionADMINpour pouvoir le modifier ou le supprimer, en plus d'avoir l'attributCREATEROLE. C'est par défaut le cas pour tous les rôles que le rôle a créés, mais pas les autres.Cf. Grant on roles et Roles attributes dans la documentation de PostgreSQL 16.
Ces changements font qu'Asgard 1.4.0 n'est pas compatible avec PostgreSQL 16. En particulier, les mécanismes grâce auxquels
g_adminétait rendu membre de tous les rôles désignés comme producteurs de schémas ne fonctionnent plus, au moins pour les rôles producteurs qui n'ont pas été créés parg_admin.Plus généralement, cette évolution a pour principe d'assurer qu'aucun rôle non super-utilisateur ne puisse maîtriser nativement tous les autres rôles non super-utilisateurs sauf à y être explicitement autorisé pour chacun d'eux. Quels que soient les correctifs mis en œuvre, le contrôle de
g_adminsur la base s'en trouvera nécessairement diminué si d'autres rôles (y compris des rôles de connexion) sont amenés à créer des rôles, sauf à ce que les administrateurs pensent à ajouterADMIN g_adminà toutes leurs commandes de création de rôles... Pour ne rien arranger, il était jusqu'ici recommandé dans la documentation d'Asgard de conférer l'attributCREATEROLEaux rôles de connexion des administrateurs pour leur éviter d'avoir à lancer unSET ROLE g_adminavant de pouvoir créer, modifier ou supprimer un rôle. Il est donc naturel que plusieurs rôles soient amenés à gérer les rôles dans le contexte actuel.Deux niveaux d'intervention sont donc à prévoir :