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.

Dans SQL Server, un compte est une connexion (login) du serveur, sans hôte ; dans chaque base, il agit à travers l'utilisateur qui lui est lié, que Calíope trouve seul. Les privilèges se répartissent en cinq portées —Global (le serveur), Connexion (une base), Base de données (un schéma), Table et Routine— et un DENY s'affiche comme un troisième état, barré et nommé : ici, on le voit mais on ne le modifie pas ; il se pose et se retire depuis l'éditeur SQL.

Sans permission de lire les comptes — dans MySQL et MariaDB, SELECT sur la base mysql — la liste indique « Impossible de lire les comptes du serveur », avec le motif du serveur en dessous et un bouton pour réessayer, et le pied n'affiche aucun nombre. Dans PostgreSQL cela n'arrive pas : n'importe quel compte peut lire les rôles. Dans SQL Server, sans VIEW ANY DEFINITION vous voyez moins de comptes, sans erreur. Et dans Sauvegardes, sans cette permission, la section des comptes du serveur n'apparaît pas.

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 de Utilisateurs. Saisissez le nom, l’hôte et le mot de passe. Le compte est créé sans privilèges et reste sélectionné, pour que vous les attribuiez aussitôt.

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. Le rôle est créé avec LOGIN et INHERIT, comme le fait CREATE USER, pour qu’il puisse se connecter ; ses autres attributs se cochent ensuite sur sa propre carte.

SQL Server non plus : le compte est une connexion (login), sans hôte et sans méthode à choisir.

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.

Dans SQL Server, supprimer retire l'utilisateur du compte dans chaque base, puis la connexion. Le serveur refuse tant qu'un de ces utilisateurs possède un schéma : confiez d'abord le schéma à quelqu'un d'autre (ALTER AUTHORIZATION).

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.

Le formulaire s’ouvre avec ce que le serveur a enregistré, à savoir si le compte est verrouillé et ses limites horaires. Une limite de 0 signifie aucune limite, et la remettre à 0 la supprime. Laissez le champ du mot de passe vide si vous ne voulez changer que le reste.

Dans SQL Server, il porte le mot de passe et le verrouillage (ALTER LOGIN … DISABLE : la connexion ne peut plus entrer et garde ses autorisations) ; il n'y a ni limites horaires ni date d'expiration par compte.

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 et SQL Server. S’appliquent à tout le serveur (p. ex. SUPER ou PROCESS dans MySQL, VIEW SERVER STATE dans SQL Server).
- Connexion — PostgreSQL et SQL Server. Dans PostgreSQL, les privilèges de la base du cluster visée par le profil : CONNECT, CREATE et TEMPORARY, qui décident si le compte peut seulement se connecter. Dans SQL Server, ceux d’une base entière (CONNECT, CREATE TABLE…).
- Base de données — sur tous les objets d’une base (dans PostgreSQL et SQL Server, 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