Mit der Version 8.0 wurde endlich das Konzept von Rollen im Usermanagement bei Oracle MySQL implementiert. Andere Distributoren (z.B. MariaDB) haben dieses nützliche Feature bereits vor längerer Zeit implementiert.

Die Spielvorbereitung

Rollen dienen im Allgemeinen dazu, eine bestimmte Anzahl von Berechtigungen zusammenzufassen. Ein Rolle kann beispielsweise die notwendigen Berechtigungen eines Applikations-Users beinhalten oder die eines Administrators (z.B. eines DBAs). Bis zur Oracle-MySQL-Version 5.7 konnten Berechtigungen nur dediziert Usern zugewiesen werden. Wollte man einen weiteren gleichberechtigten User anlegen, so hat man, zum Beispiel über ein Skript, die Rechte des Users A ausgelesen und einen User B mit den identischen Berechtigungen ausgestattet. Natürlich gab es aber keine Sicherheit, dass die User auch in Zukunft über identische Berechtigungen verfügten, da ja jederzeit jeder Account weiter manipuliert werden konnte.

Mit ein bisschen "sed"-Magie lässt sich so zum Beispiel der User "app" als User "web" kopieren.

Spielaufbau

Anstatt Rechte an User zu "granten", kann ab MySQL 8.0 das Objekt einer Rolle erzeugt und alternativ genutzt werden, um die Berechtigungen entgegenzunehmen. Dazu können eine oder mehrere Rollen erzeugt werden. In diesem Beispiel möchten wir anstatt des Users "app" zwei Rollen "app_ro" (lesender Zugriff) und "app_rw" (schreibender Zugriff) erzeugen. Diese Rollen erhalten die entsprechenden Rechte.

Spielfigur wählen

Diese vorhandenen Rollen können nun klassischen User-Accounts zugewiesen werden. Dies erfolgt über die altbekannten GRANT-Anweisungen.

Was passiert nun, wenn sich der User 'application' an der Datenbank authentifiziert?

Ok, hier scheint etwas nicht zu stimmen. Eine Rolle, sofern sie nicht bei der Vergabe als "default" gesetzt wird, muss vom User aktiv "genommen" werden. Der User hat damit in diesem Fall die Kontrolle, mit welcher Rolle er arbeiten möchte oder ob er sogar zeitgleich mehrere Rollen nutzen möchte.

Neben dem oben gezeigten "Nehmen" von einzelnen Rollen gibt auch eine Syntax, um sich alle Rollen oder alle Rollen bis auf einige wenige Ausnahmen zu nehmen:

• SET ALL
• SET NONE
• SET ALL [EXECEPT A, B, C, ...]

Mehr Details dazu finden Sie in der aktuellen Dokumentation.

Spielregeln verstehen und durchsetzen​

Wie oben bereits erwähnt, lassen sich aber auch gewisse Spielregeln erzwingen. So kann man als Administrator Usern per "default" eine Rolle auferlegen. 

Wenn ein User wissen möchte, welche Rollen und welche Rechte für ihn bereitstehen, hat er mehrere Möglichkeiten:

Der User darf über seine "default"-Rolle "app_ro" auf die "sakila"-Datenbank zugreifen. Verwirft er sein Rollenrecht, so sehen seine Rechte gleich anders aus.

Ein User hat aber auch die Möglichkeit, sich die Berechtigungen einer Rolle anzusehen, ohne diese vorher aktivieren zu müssen:

Spielschluss

Ein Rollenkonzept war überfällig. Es liegt die Vermutung nahe, dass dieses Feature nicht ganz freiwillig in MySQL implementiert wurde. Lange Zeit wurde seitens der Community danach verlangt. Oftmals war als Reaktion darauf zu hören, dass ein solches Feature für MySQL nicht notwendig sei, da MySQL oftmals in einem Umfeld (gemeint waren wahrscheinlich einfache Webapplikationen) genutzt werde, in dem nicht viele User-Accounts zum Tragen kommen (eine Applikation = ein User ?!).
Nachdem aber MariaDB dieses Konzept umgesetzt hatte, ließ sich Oracle nicht mehr lange bitten.
Was auch immer letztendlich der Grund gewesen sein mag, es erhöht den Spielspaß im MySQL-Umfeld für den Administrator aber auch für den Entwickler erheblich.

Sie haben Fragen rund um das Thema MySQL? Sprechen Sie mit uns.