Utilisateurs

Créez, modifiez et supprimez des comptes du serveur avec leurs privilèges.

Où le trouver : Espace de travail › Outils › Utilisateurs

Ouvrez Utilisateurs depuis la barre de navigation de l’espace de travail. Le panneau de gauche liste tous les comptes du serveur, ceux installés par le serveur étant regroupés à part ; le champ de recherche filtre par nom. Sélectionnez un compte pour charger ses privilèges.

Ce qui apparaît à droite dépend du moteur, car le modèle de sécurité n’est pas le même. Dans MySQL et MariaDB un compte est utilisateur@hôte et les privilèges se accordent à quatre portées : Global, Base de données, Table et Routine. Dans PostgreSQL un compte est un rôle, il n’y a pas d’hôte, et à la place de la portée globale apparaissent ses attributs, qui ne s’accordent pas mais se définissent. Ce qu’un moteur n’a pas n’est pas grisé : il n’est pas affiché.

Dans chaque carte les cases sont regroupées par Données, Structure, Routines, Administration et Réplication. Cochez ce qu’il faut et appuyez sur Enregistrer les modifications ; tant qu’il reste des modifications non appliquées l’en-tête le signale, et Annuler les modifications revient à ce qui est sur le serveur.

Mots-clés : utilisateurs, rôles, privilèges, permissions, GRANT, administration des utilisateurs

Ajoutez un compte avec son nom et son mot de passe.

Où le trouver : Utilisateurs › Nouvel utilisateur

Appuyez sur Nouvel utilisateur dans la barre d’administration des utilisateurs. Saisissez le nom et le mot de passe. Le compte est créé sans privilèges ; attribuez-les ensuite.

Le champ hôte et le sélecteur de méthode d’authentification n’apparaissent que là où le moteur les possède. PostgreSQL n’a ni l’un ni l’autre : d’où une connexion est acceptée est décidé par le fichier pg_hba.conf du serveur, et le chiffrement du mot de passe par la configuration du serveur, pas par le compte.

Mots-clés : créer utilisateur, nouvel utilisateur, CREATE USER, mot de passe

Supprimez un compte du serveur.

Où le trouver : Utilisateurs › Supprimer l'utilisateur

Sélectionnez le compte dans le panneau de gauche et appuyez sur Supprimer dans l’en-tête. Une boîte de dialogue de confirmation indique ce qui va être supprimé. L’action est irréversible.

Les comptes installés par le serveur apparaissent dans leur propre groupe et ne peuvent pas être supprimés d’ici.

Dans PostgreSQL le serveur peut refuser, et ce n’est pas un défaut de Calíope : un rôle qui possède des objets ou détient des privilèges ne peut pas être supprimé tant qu’on ne les lui a pas retirés. Calíope n’émet pas DROP OWNED BY de lui-même, car cela effacerait des données que personne n’a demandé d’effacer. Retirez d’abord ses attributions — y compris celles de « toutes les tables », qui laissent en plus un privilège par défaut — ou transférez ce qu’il possède.

Mots-clés : supprimer utilisateur, DROP USER, effacer, révoquer

Modifiez le mot de passe d’un compte existant.

Où le trouver : Utilisateurs › Modifier l'utilisateur

Sélectionnez le compte dans le panneau de gauche et appuyez sur Modifier dans l’en-tête. Le formulaire d’édition s’ouvre.

Le formulaire n’affiche que ce que le moteur possède. Dans MySQL et MariaDB il comporte le mot de passe, la méthode d’authentification, le verrouillage du compte et les limites de ressources horaires. Dans PostgreSQL il comporte le mot de passe et rien d’autre : il n’y a pas de verrouillage — on ferme un compte en lui retirant l’attribut LOGIN, visible sur sa carte — ni de limites horaires, tandis que le nombre de connexions simultanées et la date d’expiration se modifient à côté des attributs.

Laissez le champ du mot de passe vide si vous ne voulez changer que le reste.

Mots-clés : modifier mot de passe, password, modifier utilisateur, ALTER USER, identifiants, nouveau mot de passe

Assignez des permissions granulaires au niveau d'une BD, d'une table ou d'une routine spécifique.

Où le trouver : Utilisateurs › Arbre des privilèges

Chaque portée de privilèges est une carte avec son compteur d’accordés et son interrupteur WITH GRANT OPTION :

- Attributs du rôle — PostgreSQL uniquement. Ce ne sont pas des privilèges : ce sont des propriétés du rôle (LOGIN, SUPERUSER, CREATEDB…) écrites avec ALTER ROLE. Les connexions simultanées et l’expiration figurent en bas.
- Global — famille MySQL uniquement. S’appliquent à tout le serveur (p. ex. SUPER, PROCESS, REPLICATION SLAVE).
- Connexion — PostgreSQL uniquement. Les privilèges de la base du cluster visée par le profil : CONNECT, CREATE et TEMPORARY. C’est ce qui décide si le compte peut seulement se connecter.
- Base de données — sur tous les objets d’une base (dans PostgreSQL, d’un schéma).
- Table — sur une table précise.
- Routine — sur une procédure ou une fonction stockée.

Dans chaque carte les cases sont regroupées par catégorie, avec Tout cocher par groupe, et ALL PRIVILEGES est mis en avant en haut parce qu’il accorde toute la portée d’un coup.

Pour ajouter une portée absente, utilisez Ajouter un objet dans la barre du bas. Enregistrer les modifications exécute les REVOKE et GRANT nécessaires ; si le serveur en rejette un, un avertissement apparaît à côté du bouton avec le détail.

Mots-clés : privilèges, GRANT, REVOKE, base de données, table, routine, permissions granulaires, EXECUTE, SUPER

Pourquoi cet écran ne ressemble pas à celui de MySQL, et ce que signifie chaque partie.

Où le trouver : Espace de travail › Outils › Utilisateurs

PostgreSQL n’a pas d’utilisateurs et de groupes séparés : il a des rôles, et un rôle est les deux à la fois. Un rôle doté de l’attribut LOGIN permet de se connecter ; un rôle sans cet attribut sert à regrouper des privilèges et à les donner à d’autres. C’est pour cela que l’écran change de forme, et non par caprice.

Il n’y a pas d’hôte. Un compte est un simple nom. D’où une connexion est acceptée est décidé par pg_hba.conf, qui appartient au serveur et non au compte : Calíope ne l’affiche donc pas ici et ne peut pas le changer.

Les attributs ne sont pas des privilèges. SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS, INHERIT et LOGIN se définissent avec ALTER ROLE, ils ne s’accordent pas avec GRANT. À l’enregistrement, Calíope les écrit tous : ce que vous laissez décoché est désactivé. C’est ce qui rend l’écran véridique — si seuls les cochés étaient écrits, décocher une case ne la désactiverait pas et elle reviendrait toute seule à la prochaine ouverture du compte.

L’appartenance est transitive. Si app appartient à lecteurs et lecteurs à auditeurs, alors app a ce qu’a auditeurs sans que personne le lui ait accordé. La carte Membre de distingue les appartenances directes des héritées et montre le chemin de chacune. Les héritées ne peuvent pas être retirées d’ici, et c’est pourquoi elles n’ont pas de bouton : ce qu’il faudrait révoquer est le maillon, et il appartient à un autre rôle.

PUBLIC n’est pas un rôle : c’est tout le monde. Il figure dans la liste comme un compte de plus, sinon un objet accordé à tous paraîtrait privé. Par défaut PUBLIC peut se connecter à la base et exécuter n’importe quelle fonction.

Le propriétaire a tout sur ce qui lui appartient, et cela n’apparaît jamais comme une attribution. Une table fraîchement créée n’a aucune ligne de privilèges dans le catalogue, et son propriétaire peut malgré tout en faire ce qu’il veut. C’est pourquoi l’en-tête porte l’étiquette « propriétaire de N objets » et que ces cartes sont dessinées cochées et grisées : il n’y a rien à accorder ni à révoquer.

« Accorder sur toutes les tables » représente deux instructions. Dans MySQL, ON base.* couvre aussi les tables créées demain ; ici il faut deux commandes qui ne veulent pas dire la même chose : l’une atteint les tables existantes, l’autre les futures. La seconde ne couvre en outre que celles créées par le compte avec lequel Calíope est connecté. Aucune des deux ne revient ensuite sous forme de case sur la carte du schéma, car ce ne sont pas des privilèges du schéma. Le bouton voisin défait les deux, et il est nécessaire : tant que le privilège par défaut subsiste, le serveur refuse de supprimer le compte.

Ce qui n’existe pas. Pas de verrouillage de compte — on retire LOGIN —, pas de limites horaires — seulement le nombre de connexions simultanées —, pas de sélecteur de méthode d’authentification — le serveur décide — et pas de FLUSH PRIVILEGES : ici le catalogue est la source, et un GRANT est déjà en vigueur quand le serveur répond.

Mots-clés : rôles, PostgreSQL, héritage, appartenance, PUBLIC, propriétaire, attributs, LOGIN, SUPERUSER, GRANT, privilèges par défaut