Skip navigation links
5.8.7 Wann Berechtigungsänderungen wirksam werden »
Section Navigation      [Toggle]

5.8.6. Zugriffskontrolle, Phase 2: Anfrageüberprüfung

Nachdem Sie eine Verbindung hergestellt haben, wechselt der Server zu Stufe 2 der Zugriffssteuerung. Für jede Anforderung, die Sie über die Verbindung absetzen, ermittelt der Server, welche Operation Sie durchführen wollen, und überprüft dann, ob Sie die zu diesem Zweck erforderlichen Berechtigungen besitzen. Hier nun kommen die Berechtigungsspalten in den Grant-Tabellen ins Spiel. Diese Berechtigungen können aus den folgenden Tabellen stammen: user, db, host, tables_priv, columns_priv oder procs_priv. (An dieser Stelle kann es unter Umständen hilfreich sein, noch einmal Abschnitt 5.8.2, „Wie das Berechtigungssystem funktioniert“, zu lesen. Dort sind die Spalten aufgelistet, die in den verschiedenen Grant-Tabellen vorhanden sind.)

Die Tabelle user gewährt Berechtigungen, die Ihnen auf globaler Basis zugewiesen werden und die unabhängig von der gewählten Standarddatenbank gelten. Wenn die Tabelle user Ihnen beispielsweise die Berechtigung DELETE gewährt, können Sie Datensätze aus allen Tabellen in allen Datenbanken auf dem Serverhost löschen! Anders gesagt sind Berechtigungen für die Tabelle user Superuser-Berechtigungen. Es ist klug, Berechtigungen in der Tabelle user nur Superusern wie beispielsweise Datenbankadministratoren zu gewähren. Bei allen anderen Benutzern sollten Sie die Berechtigungen in der Tabelle user auf 'N' stehen lassen und Berechtigungen nur auf spezifischeren Ebenen gewähren. Sie können Berechtigungen für bestimmte Datenbanken, Tabellen, Spalten und Routinen gewähren.

Die Tabellen db und host gewähren datenbankspezifische Berechtigungen. Werte in den Bereichsspalten dieser Tabellen können die folgende Form annehmen:

  • Die Jokerzeichen ‘%’ und ‘_’ können in den Spalten Host und Db dieser Tabellen verwendet werden. Sie haben die gleiche Bedeutung wie bei Mustervergleichsoperationen, die mit dem Operator LIKE durchgeführt werden. Wenn Sie eines der Zeichen beim Gewähren von Berechtigungen literal verwenden wollen, müssen Sie es mit einem Backslash kennzeichnen. Um beispielsweise den Unterstrich (‘_’) als Teil eines Datenbanknamens zu verwenden, geben Sie ihn als ‘\_’ in der GRANT-Anweisung an.

  • Der Wert '%' in der Spalte Host der Tabelle db bedeutet „ein beliebiger Host“. Ein leerer Host-Wert in der Tabelle db hat die Bedeutung „Weitere Informationen der Tabelle host entnehmen“ (dieser Vorgang wird im weiteren Verlauf dieses Abschnitts noch beschrieben).

  • Der Wert '%' oder ein leerer Wert in der Spalte Host der Tabelle host bedeutet „ein beliebiger Host“.

  • Der Wert '%' oder ein leerer Wert in der Spalte Db in einer dieser Tabellen bedeutet „eine beliebige Datenbank“.

  • Ein leerer User-Wert in einer der Tabellen führt zur Übereinstimmung mit dem anonymen Benutzer.

Der Server liest die Tabellen db und host in den Speicher ein und sortiert sie, während er gleichzeitig die Tabelle user einliest. Der Server sortiert die Tabelle db nach den Bereichsspalten Host, Db und User und die Tabelle host nach den Bereichsspalten Host und Db. Wie bei der Sortierung der Tabelle user werden auch hier die spezifischeren Werte an den Anfang und die weniger spezifischen an das Ende der Tabelle gesetzt, und auch hier verwendet der Server bei der Suche nach Übereinstimmungen das erste passende Ergebnis.

Die Tabellen tables_priv columns_priv und proc_priv gewähren tabellenspezifische, spaltenspezifische und routinenspezifische Berechtigungen. Werte in den Bereichsspalten dieser Tabellen können die folgende Form annehmen:

  • Die Jokerzeichen ‘%’ und ‘_’ können in der Spalte Host verwendet werden. Sie haben die gleiche Bedeutung wie bei Mustervergleichsoperationen, die mit dem Operator LIKE durchgeführt werden.

  • Der Wert '%' oder ein leerer Wert in der Spalte Host bedeutet „ein beliebiger Host“.

  • Die Spalten Db, Table_name und Column_name dürfen weder Jokerzeichen enthalten noch leer sein.

Der Server sortiert die Tabellen tables_priv, columns_priv und procs_priv nach den Spalten Host, Db und User. Dies ähnelt der Sortierung der Tabelle db, ist aber einfacher, da nur die Spalte Host Jokerzeichen enthalten darf.

Der Server verwendet die sortierten Tabellen zur Verifizierung aller empfangenen Anforderungen. Bei Anforderungen, die administrative Berechtigungen voraussetzen (z. B. SHUTDOWN oder RELOAD), überprüft der Server nur den Datensatz in der Tabelle user, weil dies die einzige Tabelle ist, die administrative Berechtigungen angibt. Der Server gewährt den Zugriff, wenn der Datensatz die angeforderte Operation gestattet; andernfalls wird der Zugriff abgewiesen. Wenn Sie also beispielsweise mysqladmin shutdown ausführen wollen, aber Ihr Datensatz in der Tabelle user Ihnen die Berechtigung SHUTDOWN nicht gewährt, dann verweigert der Server Ihnen den Zugriff, ohne die Tabellen db oder host auch nur abgefragt zu haben. (Da diese Tabellen keine Shutdown_priv-Spalte enthalten, ist dies ohnehin unnötig.)

Bei datenbankbezogenen Anforderungen (INSERT, UPDATE usw.) überprüft der Server zuerst die globalen Berechtigungen (Superuser-Berechtigungen), indem er den Datensatz in der Tabelle user abfragt. Gestattet der Datensatz die angeforderte Operation, dann wird der Zugriff gewährt. Wenn die globalen Berechtigungen in der Tabelle user nicht ausreichend sind, ermittelt der Server die datenbankspezifischen Berechtigungen, indem er die Tabellen db und host überprüft:

  1. Der Server sucht in der Tabelle db nach einer Übereinstimmung der Spalten Host, Db und User. Die Spalten Host und User werden auf Übereinstimmung mit dem Hostnamen und dem MySQL-Benutzernamen des Benutzers geprüft, der die Verbindung herstellen will. Die Spalte Db wird mit der Datenbank verglichen, auf die der Benutzer zugreifen will. Kann kein Datensatz für Host und User gefunden werden, dann wird der Zugriff verweigert.

  2. Ist ein übereinstimmender Datensatz in der Tabelle db vorhanden und ist die Spalte Host nicht leer, dann definiert der Datensatz die datenbankspezifischen Berechtigungen für den Benutzer.

  3. Ist die Spalte Host im übereinstimmenden Datensatz der Tabelle db leer, dann bedeutet dies, dass die Tabelle host auflistet, welche Hosts auf die Datenbank zugreifen dürfen. In diesem Fall wird in der Tabelle host erneut eine Übereinstimmung mit den Spalten Host und Db gesucht. Wird kein passender Datensatz in der Tabelle host gefunden, dann wird der Zugriff verweigert. Wird allerdings eine Übereinstimmung gefunden, dann werden die datenbankspezifischen Berechtigungen des Benutzers als Schnittmenge (nicht als Gesamtmenge!) der Berechtigungen in den Einträgen der Tabellen db und host berechnet, d. h. die Berechtigungen müssen in beiden Einträgen jeweils 'Y' sein. (Auf diese Weise können Sie allgemeine Berechtigungen im Datensatz der Tabelle db gewähren und diese dann über die Tabelle host auf Hostbasis selektiv einschränken.)

Nachdem er die datenbankspezifischen Berechtigungen ermittelt hat, die durch die Einträge in den Tabellen db und host gewährt werden, fügt der Server diese den durch die Tabelle user gewährten Berechtigungen hinzu. Gestattet das Ergebnis die angeforderte Operation, dann wird der Zugriff gewährt. Andernfalls überprüft der Server nachfolgend die Tabellen- und Spaltenberechtigungen des Benutzers in den Tabellen tables_priv bzw. columns_priv, fügt diese den Benutzerberechtigungen hinzu und gestattet oder verweigert auf der Basis des Ergebnisses den Zugriff. Bei Operationen in Zusammenhang mit gespeicherten Routinen verwendet der Server die Tabelle procs_priv statt tables_priv und columns_priv.

Ausgedrückt in booleschen Termini, lässt sich die vorangegangene Beschreibung der Berechnung von Benutzerberechtigungen wie folgt zusammenfassen: 

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges

Es ist vielleicht nicht einleuchtend, warum der Server, wenn die globalen Berechtigungen im Datensatz der Tabelle user zunächst nicht als ausreichend für die angeforderte Operation erachtet werden, diese Berechtigungen später zu den Berechtigungen für die Datenbanken, Tabellen und Spalten hinzufügt. Der Grund hierfür besteht darin, dass eine Anforderung mehrere Berechtigungstypen erfordern kann. Wenn Sie beispielsweise eine INSERT INTO ... SELECT-Anweisung ausführen, benötigen Sie sowohl die Berechtigung INSERT als auch die Berechtigung SELECT. Ihre Berechtigungen sehen unter Umständen so aus, dass der Datensatz in der Tabelle user eine dieser Berechtigungen und der Datensatz in der Tabelle db die andere Berechtigung gewährt. In diesem Fall besitzen Sie die erforderlichen Berechtigungen, um die Anforderung durchzuführen, aber der Server kann dies nicht mithilfe nur einer Tabelle bestimmen; vielmehr müssen die von den Einträgen in beiden Tabellen gewährten Berechtigungen kombiniert werden.

Die Tabelle host wird von GRANT- und REVOKE-Anweisungen nicht beeinflusst, liegt also in den meisten MySQL-Installationen brach. Wenn Sie sie jedoch manuell modifizieren, können Sie sie für bestimmte Spezialzwecke einsetzen, z. B. um eine Liste sicherer Server zu führen. Bei TcX beispielsweise enthält die Tabelle host eine Liste aller Systeme im lokalen Netzwerk. Diesen sind alle Berechtigungen gewährt.

Sie können die Tabelle host auch verwenden, um Hosts anzugeben, die nicht sicher sind. Nehmen wir an, dass Sie einen Computer namens public.your.domain haben, der sich in einem öffentlichen Bereich befindet, den Sie als nicht sicher erachten. Sie können Zugriff auf alle Hosts in Ihrem Netzwerk mit Ausnahme dieses Computers gewähren, indem Sie die Einträge der Tabelle host wie folgt verwenden: 

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (all privileges set to 'N')
| %.your.domain      | %  | ... (all privileges set to 'Y')
+--------------------+----+-

Natürlich sollten Sie Ihre Änderungen an den Grant-Tabellen immer testen (z. B. mit SHOW GRANTS), um sicherzustellen, dass Ihre Zugriffsberechtigungen tatsächlich so konfiguriert sind, wie Sie es wünschen.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.