Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Serverkonten samt ihren Rechten anlegen, bearbeiten und löschen.
Wo es zu finden ist: Workspace › Werkzeuge › Benutzer
Öffne Benutzer über die Navigationsleiste des Arbeitsbereichs. Das linke Panel listet alle Konten des Servers auf, die vom Server installierten separat gruppiert; das Suchfeld filtert nach Namen. Wähl ein Konto aus, um seine Rechte zu laden.
Was rechts erscheint, hängt vom Motor ab, denn das Sicherheitsmodell ist nicht dasselbe. In MySQL und MariaDB ist ein Konto benutzer@host und Rechte werden auf vier Ebenen vergeben: Global, Datenbank, Tabelle und Routine. In PostgreSQL ist ein Konto eine Rolle, es gibt keinen Host, und statt der globalen Ebene erscheinen ihre Attribute, die nicht vergeben, sondern gesetzt werden. Was ein Motor nicht hat, wird nicht ausgegraut gezeichnet: es wird gar nicht gezeichnet.
Innerhalb jeder Karte sind die Kästchen nach Daten, Struktur, Routinen, Administration und Replikation gruppiert. Hak an, was zutrifft, und drück Änderungen speichern; solange es ungesicherte Änderungen gibt, sagt es die Kopfzeile, und Änderungen verwerfen kehrt zum Stand auf dem Server zurück.
In SQL Server ist ein Konto eine Anmeldung (Login) des Servers, ohne Host; in jeder Datenbank handelt es über den damit verknüpften Benutzer, den Calíope selbst findet. Die Rechte liegen in fünf Bereichen —Global (der Server), Verbindung (eine Datenbank), Datenbank (ein Schema), Tabelle und Routine—, und ein DENY erscheint als dritter Zustand, durchgestrichen und benannt: Hier sieht man es, ändert es aber nicht; gesetzt und entfernt wird es im SQL-Editor.
Ohne Berechtigung, die Konten zu lesen — in MySQL und MariaDB SELECT auf die Datenbank mysql — zeigt die Liste „Die Konten des Servers konnten nicht gelesen werden“, darunter den Grund des Servers und eine Schaltfläche zum erneuten Versuchen, und die Fußzeile zeigt keine Zahl. In PostgreSQL passiert das nicht: Jedes Konto kann die Rollen lesen. In SQL Server siehst du ohne VIEW ANY DEFINITION weniger Konten, ohne Fehler. Und unter Backups erscheint ohne diese Berechtigung der Abschnitt mit den Serverkonten nicht.
ClickHouse
Bei ClickHouse bringt die Liste Konten und Rollen zusammen. Konten, die in der Konfigurationsdatei des Servers definiert sind, und default erscheinen unter System mit einem Schloss: Sie lassen sich nicht per SQL ändern. Ein teilweiser Entzug —auf einer Datenbank gewähren und auf einer ihrer Tabellen entziehen— erscheint auf der Karte dieser Tabelle durchgestrichen und mit dem Wort REVOKE: Hier sieht man ihn, ändern lässt er sich nicht. Die Berechtigungen jeder Karte liefert der Server, also ändern sie sich mit seiner Version. Die Berechtigung zum Schreiben gehört zur Verbindung: Fehlt deinem Konto ACCESS MANAGEMENT oder CREATE USER, auch über eine Rolle, listet das Werkzeug trotzdem, aber die Schaltflächen sind aus, und ein Streifen mit einem Schloss sagt, warum. Änderungen wirken sofort, es gibt keine Stundenlimits, und zum Gewähren werden nur Rollen angeboten.
Oracle
Bei Oracle zeigt die Liste Konten und Rollen zusammen, dazu PUBLIC, die Rolle, der alle angehören; Oracles eigene Konten und Rollen stehen unter System. Jedes Konto besitzt das Schema mit seinem Namen. Die Berechtigungen verteilen sich auf vier Bereiche: Global (Systemberechtigungen wie CREATE TABLE), Datenbank (Berechtigungen auf ein ganzes Schema, etwa SELECT ANY TABLE darauf), Tabelle und Routine, wo auch die Pakete erscheinen. Darüber stehen das Profil mit seinen Passwortgrenzen, das Ablaufdatum des Passworts und der Tablespace: Sie werden gelesen, nicht hier geändert. Bei PUBLIC und Oracles Konten wird nur gezeigt, was auf Benutzerschemas gewährt ist. Ohne Leserecht auf DBA_USERS zeigt die Liste nur dein Konto mit seinen Rollen und Berechtigungen, und ein Hinweisband sagt es. Berechtigungen auf Sequenzen, Typen und Spalten werden nicht gezeigt. Schreiben braucht pro Aktion eine Systemberechtigung deiner Verbindung: CREATE USER zum Anlegen, ALTER USER zum Ändern des Passworts oder Sperren, DROP USER zum Löschen und GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE oder GRANT ANY ROLE zum Gewähren; ohne sie ist die Schaltfläche deaktiviert und nennt die fehlende. Oracles eigene Konten werden hier nicht geändert: Ein Hinweisband sagt es.
Mit einem schreibgeschützten Umgebungsetikett wird dieses Werkzeug nicht angeboten. Bei einem, das Schreibzugriffe bestätigt, fragt jede Änderung – einen Benutzer anlegen oder bearbeiten, seine Rechte, seine Rollen – vorher mit dem Namen der Aktion, und das Löschen eines Benutzers trägt das Etikett im Titel seiner Bestätigung.
Drück Neuer Benutzer in der Leiste von Benutzer. Gib Namen, Host und Passwort ein. Das Konto wird ohne Rechte angelegt und bleibt ausgewählt, damit du sie gleich vergeben kannst.
Das Feld Host und die Auswahl der Authentifizierungsmethode erscheinen nur dort, wo der Motor sie hat. PostgreSQL hat weder das eine noch das andere: von wo eine Verbindung angenommen wird, entscheidet die Datei pg_hba.conf des Servers, und wie das Passwort verschlüsselt wird, entscheidet die Serverkonfiguration, nicht das Konto. Die Rolle wird mit LOGIN und INHERIT angelegt, wie es CREATE USER tut, damit sie sich anmelden kann; ihre übrigen Attribute werden danach auf ihrer eigenen Karte angekreuzt.
SQL Server auch nicht: Das Konto ist eine Anmeldung, ohne Host und ohne Methode zur Auswahl.
Oracle
Bei Oracle gibt es weder Host noch Methode: Das Konto wird mit CREATE USER … IDENTIFIED BY angelegt und erhält CREATE SESSION, womit es sich anmelden kann. Das Passwort darf keine doppelten Anführungszeichen enthalten. Ohne Passwort entsteht ein reines Schemakonto (NO AUTHENTICATION), das Objekte hält, sich aber nicht anmelden kann. Tablespace und Kontingent legt der Server fest: Ohne Kontingent speichert das Konto keine Zeilen, und du vergibst es im SQL-Editor (ALTER USER … QUOTA). In einer Pluggable Database (PDB) gehört ein Name, der mit C## beginnt, zu einem gemeinsamen Benutzer und wird hier nicht angelegt: Das Formular sagt es.
Wähl das Konto im linken Panel aus und drück Löschen in der Kopfzeile. Ein Bestätigungsdialog zeigt, was entfernt wird. Die Aktion ist nicht umkehrbar.
Die vom Server installierten Konten erscheinen in einer eigenen Gruppe und lassen sich hier nicht löschen.
In PostgreSQL kann der Server sich weigern, und das ist kein Fehler von Calíope: eine Rolle, die Objekte besitzt oder Rechte hält, lässt sich nicht löschen, solange man sie ihr nicht entzieht. Calíope setzt keinDROP OWNED BY von sich aus ab, denn das würde Daten löschen, die niemand zu löschen verlangt hat. Entzieh zuerst ihre Rechte — auch die von „alle Tabellen“, die zusätzlich ein Standardrecht hinterlassen — oder übertrag, was sie besitzt.
In SQL Server entfernt das Löschen den Benutzer des Kontos in jeder Datenbank und danach die Anmeldung. Der Server lehnt ab, solange einer dieser Benutzer ein Schema besitzt: Übertrage das Schema vorher an jemand anderen (ALTER AUTHORIZATION).
Oracle
Bei Oracle ist ein Konto sein Schema: Es zu löschen ist DROP USER … CASCADE, das auch alle Tabellen, Views und den Code löscht, und die Bestätigung sagt es. Eine Rolle wird mit DROP ROLE gelöscht. Oracles eigene Konten werden hier nicht gelöscht.
Stichwörter: benutzer löschen, DROP USER, entfernen, widerrufen
Wo es zu finden ist: Benutzer › Benutzer bearbeiten
Wähl das Konto im linken Panel aus und drück Bearbeiten in der Kopfzeile. Das Bearbeitungsformular öffnet sich.
Das Formular zeigt nur, was der Motor hat. In MySQL und MariaDB enthält es das Passwort, die Authentifizierungsmethode, die Kontosperre und die stündlichen Ressourcengrenzen. In PostgreSQL enthält es das Passwort und sonst nichts: es gibt keine Sperre — ein Konto wird geschlossen, indem man ihm das Attribut LOGIN nimmt, das auf seiner Karte steht — und keine stündlichen Grenzen, während die gleichzeitigen Verbindungen und das Ablaufdatum neben den Attributen bearbeitet werden.
Das Formular öffnet sich mit dem, was der Server gespeichert hat: ob das Konto gesperrt ist und seine stündlichen Grenzen. Eine Grenze von 0 bedeutet unbegrenzt, und sie wieder auf 0 zu setzen, hebt sie auf. Lass das Passwortfeld leer, wenn du nur die übrigen Einstellungen ändern willst.
In SQL Server enthält es das Passwort und die Sperre (ALTER LOGIN … DISABLE: Die Anmeldung kann nicht mehr hinein und behält ihre Rechte); es gibt keine Stundenlimits und kein Ablaufdatum pro Konto.
Oracle
Bei Oracle enthält es das Passwort und die Sperre (ALTER USER … ACCOUNT LOCK: Das Konto kann sich nicht anmelden, und der Server antwortet mit ORA-28000). Stündliche Grenzen gibt es nicht: Die Passwortgrenzen kommen aus dem Profil, das im Kopf des Kontos steht. Das Passwort darf keine doppelten Anführungszeichen enthalten.
Weise granulare Rechte auf Ebene einer bestimmten DB, Tabelle oder Routine zu.
Wo es zu finden ist: Benutzer › Berechtigungsbaum
Jede Rechte-Ebene ist eine Karte mit ihrem Zähler der vergebenen Rechte und ihrem Schalter WITH GRANT OPTION:
- Rollenattribute — nur PostgreSQL. Das sind keine Rechte, sondern Eigenschaften der Rolle (LOGIN, SUPERUSER, CREATEDB…), die mit ALTER ROLE geschrieben werden. Gleichzeitige Verbindungen und Ablaufdatum stehen unten.
- Global — MySQL-Familie und SQL Server. Gelten für den ganzen Server (z. B. SUPER oder PROCESS in MySQL, VIEW SERVER STATE in SQL Server).
- Verbindung — PostgreSQL und SQL Server. In PostgreSQL die Rechte der Cluster-Datenbank, auf die das Profil zeigt: CONNECT, CREATE und TEMPORARY, die entscheiden, ob das Konto sich überhaupt verbinden kann. In SQL Server die über eine ganze Datenbank (CONNECT, CREATE TABLE…).
- Datenbank — über alle Objekte einer Datenbank (in PostgreSQL und SQL Server: eines Schemas).
- Tabelle — über eine bestimmte Tabelle.
- Routine — über eine gespeicherte Prozedur oder Funktion.
Innerhalb jeder Karte sind die Kästchen nach Kategorie gruppiert, mit Alle auswählen je Gruppe, und ALL PRIVILEGES steht hervorgehoben oben, weil es die ganze Ebene auf einmal vergibt.
Um eine fehlende Ebene hinzuzufügen, nutz Objekt hinzufügen in der unteren Leiste. Änderungen sichern führt die nötigen REVOKE und GRANT aus; lehnt der Server eines ab, erscheint neben der Taste ein Hinweis mit den Einzelheiten. Bei MySQL und MariaDB folgt danach FLUSH PRIVILEGES, ebenso beim Anlegen, Bearbeiten und Löschen eines Kontos.
ClickHouse
Mit ClickHouse gibt es drei Karten: Global, Datenbank und Tabelle. Es gibt weder Routine noch Verbindung noch Rollenattribute.
Oracle
Mit Oracle gibt es vier Karten: Global (die Systemberechtigungen; ihr Schalter ist die ADMIN OPTION), Datenbank (Berechtigungen auf ein ganzes Schema, etwa SELECT ANY TABLE ON SCHEMA), Tabelle (auch Views und materialisierte Views) und Routine (Prozeduren, Funktionen und Pakete). Es gibt keine Verbindung und keine Rollenattribute.
Warum dieser Bildschirm nicht wie der von MySQL aussieht und was jeder Teil bedeutet.
Wo es zu finden ist: Workspace › Werkzeuge › Benutzer
PostgreSQL kennt keine getrennten Benutzer und Gruppen: es kennt Rollen, und eine Rolle ist beides zugleich. Eine Rolle mit dem Attribut LOGIN kann sich anmelden; eine ohne dieses Attribut dient dazu, Rechte zu bündeln und sie anderen zu geben. Deshalb ändert der Bildschirm seine Form, und nicht aus einer Laune heraus.
Es gibt keinen Host. Ein Konto ist ein blosser Name. Von wo eine Verbindung angenommen wird, entscheidet pg_hba.conf, die zum Server gehört und nicht zum Konto — Calíope zeigt das hier also nicht und kann es nicht ändern.
Attribute sind keine Rechte.SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS, INHERIT und LOGIN werden mit ALTER ROLE gesetzt, nicht mit GRANT vergeben. Beim Sichern schreibt Calíope sie alle: was du nicht ankreuzt, wird ausgeschaltet. Das macht den Bildschirm wahrhaftig — würde nur das Angekreuzte geschrieben, schaltete das Abwählen eines Kästchens es nicht aus und es käme beim nächsten Öffnen des Kontos von selbst zurück.
Mitgliedschaft ist transitiv. Gehört app zu leser und leser zu prüfer, dann hat app, was prüfer hat, ohne dass es ihr jemand vergeben hätte. Die Karte Mitglied von unterscheidet direkte von geerbten Mitgliedschaften und zeigt den Weg jeder einzelnen. Geerbte lassen sich hier nicht entfernen, und darum haben sie keine Taste: zu widerrufen wäre das Glied, und das gehört einer anderen Rolle.
PUBLIC ist keine Rolle: das sind alle. Es steht als weiteres Konto in der Liste, denn sonst sähe ein allen gewährtes Objekt privat aus. Standardmässig darf PUBLIC sich mit der Datenbank verbinden und jede Funktion ausführen.
Der Eigentümer hat alles über das Seine, und das erscheint nie als Vergabe. Eine frisch angelegte Tabelle hat im Katalog überhaupt keine Rechtezeile, und ihr Eigentümer kann trotzdem alles damit tun. Darum trägt die Kopfzeile die Marke „Eigentümer von N Objekten“ und diese Karten werden angekreuzt und ausgegraut gezeichnet: es gibt nichts zu vergeben und nichts zu entziehen.
„Auf alle Tabellen gewähren“ sind zwei Anweisungen. In MySQL deckt ON datenbank.* auch morgen angelegte Tabellen ab; hier braucht es zwei Befehle, die nicht dasselbe bedeuten: einer erreicht die jetzt vorhandenen Tabellen, der andere die künftigen. Der zweite deckt zudem nur jene ab, die das Konto anlegt, mit dem Calíope verbunden ist. Keiner von beiden kommt danach als Kästchen auf der Schema-Karte zurück, denn es sind keine Schema-Rechte. Die Taste daneben macht beide rückgängig, und sie wird gebraucht: solange das Standardrecht bestehen bleibt, lässt der Server das Konto nicht löschen.
Was es nicht gibt. Keine Kontosperre — man nimmt LOGIN weg —, keine stündlichen Grenzen — nur die Zahl gleichzeitiger Verbindungen —, keine Auswahl der Authentifizierungsmethode — das entscheidet der Server — und kein FLUSH PRIVILEGES: hier ist der Katalog die Quelle, und ein GRANT gilt bereits, wenn der Server antwortet.