Rechte zuweisen und entziehen. Berechtigungen festlegen grant-Befehl Verwenden von Ansichten zum Filtern von Berechtigungen

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) TO user_name "password"] [, user_name ...] ] ] ] ] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) FROM user_name [, user_name ...]

GRANT ist in MySQL Version 3.22.11 und höher enthalten. In früheren Versionen von MySQL hat die GRANT-Anweisung keine Wirkung.

Mit den Befehlen GRANT und REVOKE können Systemadministratoren MySQL-Benutzer erstellen und Benutzern Rechte auf vier Berechtigungsebenen gewähren oder entziehen:

Globale Ebene Globale Berechtigungen gelten für alle Datenbanken auf dem angegebenen Server. Diese Berechtigungen werden in der Tabelle mysql.user gespeichert. Datenbankebene Datenbankrechte gelten für alle Tabellen in der angegebenen Datenbank. Diese Berechtigungen werden in den Tabellen mysql.db und mysql.host gespeichert. Tischebene Tabellenrechte gelten für alle Spalten der angegebenen Tabelle. Diese Berechtigungen werden in der Tabelle mysql.tables_priv gespeichert. Spaltenebene Spaltenrechte gelten für einzelne Spalten in der angegebenen Tabelle. Diese Berechtigungen werden in der Tabelle mysql.columns_priv gespeichert.

Wenn einem nicht vorhandenen Benutzer Berechtigungen gewährt werden, wird dieser Benutzer erstellt. Beispiele für den GRANT-Befehl finden Sie in Abschnitt 4.3.5 Hinzufügen neuer Benutzer zu MySQL.

Die Tabelle zeigt eine Liste möglicher Werte für den Parameter priv_type für die Anweisungen GRANT und REVOKE:

ALLE	Legt alle einfachen Berechtigungen außer WITH GRANT OPTION fest
ÄNDERN	Ermöglicht die Verwendung von ALTER TABLE
ERSTELLEN	Ermöglicht die Verwendung von CREATE TABLE
Temporäre Tabellen erstellen	Ermöglicht die Verwendung von CREATE TEMPORARY TABLE
LÖSCHEN	Ermöglicht die Verwendung von DELETE
FALLEN	Ermöglicht die Verwendung von DROP TABLE.
AUSFÜHREN	Ermöglicht dem Benutzer die Ausführung gespeicherter Prozeduren (für MySQL 5.0)
DATEI	Ermöglicht die Verwendung von SELECT ... INTO OUTFILE und LOAD DATA INFILE .
INDEX	Ermöglicht die Verwendung von CREATE INDEX und DROP INDEX
EINFÜGEN	Ermöglicht die Verwendung von INSERT
SPERRTISCHE	Ermöglicht die Verwendung von LOCK TABLES für Tabellen, die über die SELECT-Berechtigung verfügen.
VERFAHREN	Ermöglicht die Verwendung von SHOW FULL PROCESSLIST
VERWEISE	Reserviert für zukünftige Verwendung
NEU LADEN	Ermöglicht die Verwendung von FLUSH
REPLIKATIONS-CLIENT	Gewährt dem Benutzer das Recht, den Standort der Master- und Slave-Server abzufragen.
REPLIKATIONS-SKLAVE	Notwendig für Slave-Server während der Replikation (zum Lesen von Informationen aus den Binärprotokollen des Hauptservers).
WÄHLEN	Ermöglicht die Verwendung von SELECT
DATENBANKEN ANZEIGEN	SHOW DATABASES Listet alle Datenbanken auf.
ABSCHALTEN	Ermöglicht die Verwendung von mysqladmin Shutdown
SUPER	Ermöglicht Ihnen, eine Verbindung (einmalig) herzustellen, auch wenn max_connections erreicht ist, und die Befehle CHANGE MASTER, KILL thread, mysqladmin debug, PURGE MASTER LOGS und SET GLOBAL auszuführen
AKTUALISIEREN	Ermöglicht die Verwendung von UPDATE
VERWENDUNG	Synonym für „ohne Privilegien“.

Der USAGE-Wert kann angegeben werden, wenn Sie einen Benutzer ohne Berechtigungen erstellen müssen.

Die Berechtigungen CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION ..., SHOW DATABASES und SUPER sind neu in Version 4.0.2. Um diese neuen Berechtigungen nach dem Upgrade auf Version 4.0.2 nutzen zu können, müssen Sie das Skript mysql_fix_privilege_tables ausführen.

In älteren Versionen von MySQL gewährt das PROCESS-Privileg die gleichen Rechte wie das neue SUPER-Privileg.

Um die durch den GRANT-Befehl gewährten Berechtigungen eines Benutzers zu widerrufen, verwenden Sie den priv_type-Wert in der GRANT-OPTION:

Mysql> REVOKE GRANT OPTION ON ... FROM ...;

Die einzigen priv_type-Werte, die für eine Tabelle angegeben werden können, sind: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, IDEX und ALTER.

Die einzigen priv_type-Werte, die für eine Spalte angegeben werden können (bei Verwendung des Column_list-Operators), sind SELECT, INSERT und UPDATE.

Globale Berechtigungen können mit der Syntax ON *.* und Datenbankberechtigungen mit der Syntax ON db_name.* festgelegt werden. Wenn Sie ON * angeben, während die aktuelle Datenbank geöffnet ist, werden Berechtigungen für diese Datenbank festgelegt. ( Warnung: wenn Sie ON * wann angeben Abwesenheit Die aktuelle Datenbank ist geöffnet, dies wirkt sich auf die globalen Berechtigungen aus!)

Um Rechte für Benutzer auf bestimmten Computern definieren zu können, bietet MySQL die Möglichkeit, den Benutzernamen (user_name) im Formular anzugeben. Wenn Sie eine Benutzerzeichenfolge angeben müssen, die Sonderzeichen (z. B. „-“) enthält, oder eine Hostzeichenfolge, die Sonder- oder Platzhalterzeichen (z. B. „%“) enthält, können Sie den Namen einschließen entfernter Computer oder Benutzer in Anführungszeichen (z. B. „Testbenutzer“@„Testhostname“).

Sie können auch Platzhalter in den Namen des Remote-Computers einfügen. Beispielsweise bezieht sich „%.loc.gov“ auf den Benutzer aller Remotecomputer in der Domäne loc.gov und „144.155.166.%“ auf den Benutzer aller Remotecomputer im Klasse-C-Subnetz 144.155.166.

Die einfache Form user ist ein Synonym für „%“.

MySQL unterstützt keine Platzhalter in Benutzernamen. Anonyme Benutzer werden definiert, indem User=""-Datensätze in die Tabelle mysql.user eingefügt werden oder indem mit dem Befehl GRANT ein Benutzer mit einem leeren Namen erstellt wird.

Notiz: Wenn anonyme Benutzer eine Verbindung zum MySQL-Server herstellen dürfen, müssen Sie auch allen lokalen Benutzern Berechtigungen gewähren, da andernfalls die Tabelle mysql.user den anonymen Benutzer verwendet, wenn ein Benutzer versucht, sich vom lokalen Computer aus bei MySQL anzumelden Anmeldung!

Um zu überprüfen, ob dies auf Ihrem Computer passiert, führen Sie die folgende Abfrage aus:

Mysql> SELECT Host,User FROM mysql.user WHERE User="";

Derzeit unterstützt der GRANT-Befehl Namen von Remote-Computern, Tabellen, Datenbanken und Spalten mit bis zu 60 Zeichen. Der Benutzername darf nicht mehr als 16 Zeichen enthalten.

Berechtigungen für eine Tabelle oder Spalte werden mithilfe des logischen ODER-Operators aus den Berechtigungen auf jeder der vier Ebenen gebildet. Wenn beispielsweise die Tabelle mysql.user angibt, dass der Benutzer über die globale SELECT-Berechtigung verfügt, wird diese Berechtigung nicht auf Datenbank-, Tabellen- oder Spaltenebene widerrufen.

Die Privilegien für eine Spalte können wie folgt berechnet werden:

Globale Privilegien ODER (Datenbankprivilegien UND Remote-Computerprivilegien) ODER Tabellenprivilegien ODER Spaltenprivilegien

In den meisten Fällen werden Benutzerrechte nur auf einer Berechtigungsstufe definiert, daher ist dieser Vorgang in der Regel nicht so komplex wie oben beschrieben. genaue Information Der Handlungsablauf zur Überprüfung der Berechtigungen wird im Abschnitt 4.2 Allgemeine Sicherheitsfragen und das MySQL-Zugriffsberechtigungssystem dargestellt.

Wenn einer Benutzer-/Remote-Kombination Berechtigungen gewährt werden, die nicht in der Tabelle mysql.user enthalten ist, wird ein Eintrag zur Tabelle mysql.user hinzugefügt und verbleibt in der Tabelle, bis er mit dem DELETE-Befehl gelöscht wird. Mit anderen Worten: Der GRANT-Befehl kann Benutzerdatensätze in der Tabelle erstellen, der REVOKE-Befehl kann sie jedoch nicht löschen. Dies muss mit dem DELETE-Befehl erfolgen.

Wenn Sie über Datenbankrechte verfügen, wird bei Bedarf ein Eintrag in der Tabelle mysql.db erstellt. Dieser Eintrag wird gelöscht, nachdem alle Berechtigungen für diese Datenbank mit dem REVOKE-Befehl entfernt wurden.

Wenn ein Benutzer keine Berechtigungen für eine Tabelle hat, wird die Tabelle nicht angezeigt, wenn der Benutzer eine Liste von Tabellen anfordert (z. B. mit der SHOW TABLES-Anweisung).

Die WITH GRANT OPTION-Anweisung gibt einem Benutzer die Möglichkeit, anderen Benutzern alle Berechtigungen zu erteilen, die er selbst auf einer bestimmten Berechtigungsstufe hat. Bei der Vergabe des GRANT-Privilegs ist Vorsicht geboten, da zwei Benutzer mit unterschiedlichen Privilegien ihre Privilegien kombinieren können!

Die Optionen MAX_QUERIES_PER_HOUR # , MAX_UPDATES_PER_HOUR # und MAX_CONNECTIONS_PER_HOUR # sind neu in MySQL Version 4.0.2. Diese Einstellungen begrenzen die Anzahl der Anfragen, Aktualisierungen und Anmeldungen, die ein Benutzer in einer Stunde durchführen kann. Bei der Einstellung 0 (Standardeinstellung) bedeutet dies, dass für diesen Benutzer keine Einschränkungen gelten. Siehe Sektion.

Sie können einem anderen Benutzer keine Berechtigung erteilen, die Sie nicht haben. Mit der GRANT-Berechtigung können Sie nur die Berechtigungen erteilen, die Sie besitzen.

Beachten Sie, dass, wenn einem Benutzer die GRANT-Berechtigung auf einer bestimmten Berechtigungsebene zugewiesen wird, diesem Benutzer auch alle Berechtigungen zugewiesen werden können, die dieser Benutzer auf dieser Ebene bereits besitzt (oder in Zukunft zugewiesen werden wird!). Nehmen wir an, dass einem Benutzer die INSERT-Berechtigung für eine Datenbank gewährt wurde. Wenn Sie dann das SELECT-Privileg in der Datenbank gewähren und WITH GRANT OPTION angeben, kann der Benutzer nicht nur das SELECT-Privileg, sondern auch das INSERT-Privileg gewähren. Wenn Sie dem Benutzer dann das UPDATE-Privileg in der Datenbank gewähren, kann der Benutzer INSERT, SELECT und UPDATE ausführen.

ALTER-Berechtigungen sollten nicht regulären Benutzern zugewiesen werden. Dies gibt dem Benutzer die Möglichkeit, das Privilegiensystem durch Umbenennen von Tabellen zu durchbrechen!

Bitte beachten Sie, dass, wenn Tabellen- oder Spaltenprivilegien auch nur für einen Benutzer verwendet werden, der Server die Tabellen- und Spaltenprivilegien für alle Benutzer überprüft und MySQL dadurch etwas verlangsamt wird.

Beim Start von mysqld werden alle Berechtigungen in den Speicher eingelesen. Datenbank-, Tabellen- und Spaltenprivilegien werden sofort wirksam, während Privilegien auf Benutzerebene wirksam werden, wenn der Benutzer das nächste Mal eine Verbindung herstellt. Änderungen an den Berechtigungszuweisungstabellen, die mit den Befehlen GRANT und REVOKE vorgenommen werden, werden vom Server sofort verarbeitet. Wenn Sie Berechtigungszuweisungstabellen manuell ändern (mit INSERT , UPDATE usw.), müssen Sie die Anweisung FLUSH PRIVILEGES oder mysqladmin flush-privilege s ausführen, um den Server anzuweisen, die Berechtigungszuweisungstabellen neu zu laden. Siehe Abschnitt 4.3.3 Wann Berechtigungsänderungen wirksam werden.

Die wichtigsten Unterschiede zwischen den ANSI SQL- und MySQL-Versionen des GRANT-Befehls sind folgende:

• In MySQL werden Berechtigungen der Kombination aus Benutzername + Remote-Computer zugewiesen, nicht nur dem Benutzernamen.
• ANSI SQL verfügt nicht über Berechtigungen auf globaler Ebene oder auf Datenbankebene, und ANSI SQL unterstützt nicht alle MySQL-Berechtigungstypen. MySQL hingegen unterstützt die ANSI SQL TRIGGER-, EXECUTE- oder UNDER-Berechtigungen nicht.
• Die ANSI-SQL-Berechtigungsstruktur ist hierarchisch. Wenn Sie einen Benutzer löschen, werden alle diesem Benutzer zugewiesenen Berechtigungen widerrufen. In MySQL werden zugewiesene Berechtigungen nicht automatisch widerrufen; Sie müssen sie bei Bedarf selbst entfernen.
• In MySQL kann ein Benutzer eine Tabelle einfügen, wenn er nur für einige Spalten dieser Tabelle über die INSERT-Berechtigung verfügt. Spalten, die nicht über die INSERT-Berechtigung verfügen, werden auf ihre Standardwerte gesetzt. ANSI SQL erfordert INSERT-Berechtigungen für alle Spalten.
• Wenn Sie eine Tabelle in ANSI SQL löschen, werden alle Berechtigungen für diese Tabelle widerrufen. Wenn Sie ein Privileg in ANSI SQL widerrufen, werden auch alle Privilegien widerrufen, die auf Grundlage dieses Privilegs zugewiesen wurden. In MySQL können Berechtigungen nur mit dem REVOKE-Befehl oder durch Ändern der MySQL-Berechtigungszuweisungstabellen entfernt werden.

Eine Beschreibung der Verwendung von REQUIRE finden Sie im Abschnitt 4.3.9 Verwenden sicherer Verbindungen.

Benutzerkommentare

Gepostet von Frank Wortner

[Löschen] [Bearbeiten]

Ich hatte keine Probleme mit ld. DEC (Compaq) könnte
habe ld in einem Patch-Kit behoben. Du möchtest vielleicht
Installieren Sie das neueste Patch-Kit für Ihr Digital Unix
(Tru64 Unix) vor dem Erstellen von MySQL. Patch-Kits
sind erhältlich unter
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Gepostet von am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Bei Quellinstallationen beziehen sich diese Anweisungen auf die Verzeichnisstruktur unter der Annahme, dass „usr/local“ (Standard) mit configure verwendet wurde. Die Anweisungen auf der vorherigen Seite (zur Kompilierung/Installation) empfehlen jedoch die Verwendung von:

./configure --prefix=/usr/local/mysql

Um konsistent zu sein (und das bereitet mir einige Probleme mit Perl, es ist also nicht rein semantisch), sollten die Anweisungen auf dieser Seite davon ausgehen, dass /usr/local/mysql mit configure als Installationsverzeichnis angegeben wurde.

Gepostet von Linda Wright am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Dies ist wahrscheinlich das Wichtigste und Geringste
geschätzte Abschnitte aller MySQL
Dokumentation für MySQL-Erstbenutzer. MEINER BESCHEIDENEN MEINUNG NACH,
Lesen dieser Seite in Verbindung mit
http://www.mysql.com/doc/P/r/Privileges.html ist ein
Ein Muss für die Planung sicherer Datenbanksysteme
von wirklicher Raffinesse.

Gepostet von Christopher Raymond am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Ich versuche, MySQL unter der öffentlichen Betaversion von OS X zu installieren. Wenn ich das Skript mysql_install_db ausführe, erhalte ich eine Fehlermeldung:

Dyld: ./bin/mysqld kann die Bibliothek nicht öffnen: /usr/lib/libpthread.A.dylib (Keine solche Datei oder kein solches Verzeichnis, errno = 2)
Die Installation der Grant-Tabellen ist fehlgeschlagen!

Ich gehe davon aus, dass das Skript nach einem Verzeichnis sucht, das nicht existiert, da Apple eine etwas andere Verzeichnisbenennungsstruktur hat. Möglicherweise muss dieses Skript für die OS X-Distribution geändert werden.

Kann jemand helfen?

Gepostet von Mark Zieg am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Es wäre schön, wenn es eine Option gäbe, Verbindungen zu protokollieren, aber keine Abfragen.

Gepostet von Bennett Haselton am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Wenn Sie als MySQL-Root-Benutzer angemeldet sind, ohne dass eine aktuelle Datenbank ausgewählt ist, und Sie dies versuchen
Gewähren Sie einem Benutzer alle Berechtigungen mit dem Befehl:

GEWÄHREN SIE BHASELTO ALLE PRIVILEGIEN FÜR *

Dann werden RELOAD, SHUTDOWN, PROCESS, FILE und GRANT nicht wie möglich gewährt
Dies wird durch Überprüfung der Tabelle „user“ der Datenbank „mysql“ überprüft. (Dies ist vermutlich beabsichtigt,
da diese Privilegien einen Benutzer „zu mächtig“ machen können.)

Gepostet von DC Hill am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

HINWEIS: Wenn Sie einem Benutzer Berechtigungen für eine bestimmte Datenbank oder auf einer niedrigeren Ebene als dieser gewährt haben, rufen Sie „REVOKE ALL ON *.* FROM ;“ auf. wird die Privilegien auf diesen Ebenen NICHT entziehen. Das *.* in der obigen Anweisung bedeutet „global“, nicht „alle (einzelnen) Tabellen in allen (einzelnen) Datenbanken. Diese Anweisung widerruft NUR globale Privilegien, wie sie in der Tabelle mysql.user gespeichert sind. Sie MÜSSEN alle spezifischeren widerrufen Privilegien auf die gleiche Weise, wie sie gewährt wurden, wenn Sie möchten, dass sie aus den Privilegientabellen entfernt werden. (d. h. - GRANT ALL ON foo.* TO ; => REVOKE ALL ON foo.* FROM ;) Ich hoffe, das spart einiges Sie ein wenig Zeit und Frust.

Gepostet von Cris Perdue am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

„Wenn Sie das Prozessprivileg haben, können Sie sehen
Alle Themen.
Ansonsten können Sie nur Ihre eigenen Threads sehen.“

Gepostet von FreeBSD Forums am Samstag, 16. Februar 2002, um 22:21 Uhr

[Löschen] [Bearbeiten]

Mit dem webbasierten Tool phpMyAdmin können Sie viele Dinge tun
von MySQL-Administratorfunktionen. href="http://www.freebsdforums.org"
>FreeBSD-Foren

Gepostet von am Montag, 25. Februar 2002, um 6:03 Uhr

[Löschen] [Bearbeiten]

Verifiziert unter MySQL 3.23.36 unter Red Hat Linux 7.1:
Beachten Sie Folgendes, wenn Sie Folgendes eingeben:
benutze a_c;
grant select on * to ;
Sie erhalten Zugriff auf alle
Datenbank, die mit „a_c“ übereinstimmt, wobei der Unterstrich ein ist
Platzhalter. (Selten ein Problem, nehme ich an).
Korrigieren Sie mit
update mysql.db set db="a\_c" where db="a_c";

Gepostet von Jan Behrens am Dienstag, 9. Juli 2002, um 1:31 Uhr

[Löschen] [Bearbeiten]

Der oben erwähnte Fehler von DAN ELIN in x.x.41 ist
Anscheinend noch gültig in x.x.51, ich kann mich nicht bei a anmelden
Datenbank nach GEWÄHREN von Privilegien und gegebenem a
Passwort für einen neuen Benutzer (ja, ich habe gespült
Berechtigungen).............Es ist nur Root-Zugriff möglich

Gepostet von Dan Egli am Donnerstag, 4. April 2002, um 20:33 Uhr

[Löschen] [Bearbeiten]

Es scheint einen Fehler in 3.23.41 bei der Verwendung von Grant zu geben.
Auf die MySQL-Datenbank kann sogar nur Root zugreifen
nachdem Sie Grant verwendet haben, um Privilegien für irgendetwas zu gewähren
Datenbank/Tabelle/Spalte/ect.. erhalten Sie immer
Die Erlaubnis wurde trotzdem verweigert.

Gepostet von Lars Aronsson am Samstag, 8. Juni 2002, um 11:16 Uhr

["%". Wenn ich versuche, sie zu löschen, wird mir eine bestimmte Datenbank mitgeteilt, aber keine globalen Berechtigungen CREATE TEMPORARY TABLE-Berechtigung für diese Datenbank ist abgelehnt. Sie müssen global CREATE __ und __ global angeben TEMPORÄRE TABELLEN ERSTELLEN für den Benutzer. IOW: GRANT CREATE, TEMPORÄRE TABELLEN ERSTELLEN AUF *.* TO ; Es versteht sich von selbst, dass dies erhebliche Auswirkungen auf die Sicherheit hat. Gepostet von am Sonntag, 25. August 2002, um 9:17 Uhr [Löschen] [Bearbeiten] Temporäre Dateien sind eine tolle Idee, aber auch mit Rechte zum Erstellen und Erstellen temporärer Dateien im Benutzerdatei (globale Rechte) funktioniert es immer noch nicht. Dies scheint schlecht konzipiert zu sein. Gepostet von Brad Bulger am Montag, 2. September 2002, um 4:09 Uhr [Löschen] [Bearbeiten] Es ist zu beachten, dass nur WITH GRANT OPTION möglich ist ermöglicht es dem Benutzer, Berechtigungen an Benutzer weiterzugeben, die existieren bereits. Die automatische Erstellung eines Benutzers Aufzeichnungen nicht Bewerben Sie sich – Sie erhalten eine Fehlermeldung dass der Benutzer mit der GRANT OPTION-Berechtigung dies tut Sie haben keinen Zugriff auf die Datenbank „mysql“. Das ist Wahrscheinlich eine gute Sache, aber es muss dokumentiert werden. Gepostet von Michael Babcock am Freitag, 8. November 2002, um 13:00 Uhr [Löschen] [Bearbeiten] Für SHOW MASTER STATUS sind PROCESS-Berechtigungen erforderlich. Andere solche ungeraden Kombinationen sollten dokumentiert werden. Gepostet von Dee Kintaudi am Donnerstag, 21. November 2002, um 12:42 Uhr [Löschen] [Bearbeiten] Okay, ich habe eine Frage und ein Problem mit MySQL und Passwörter:). Ich habe versucht, mehrere der Optionen zu nutzen und die meisten davon haben nicht funktioniert. Allerdings eins Die Lösung hat funktioniert und ich habe sie zweimal getestet war solide. Natürlich habe ich das kleine Stück Papier verloren Ich habe es auf geschrieben und kann es scheinbar nicht finden irgendwo eine Lösung finden, als gäbe es sie nicht, oder vielleicht auch ich habe es mir vorgestellt. Die Lösung, die für mich funktioniert hat, bevor ich den kleinen Zettel verlor, auf den ich es geschrieben hatte geht ungefähr so..... Einfügen in Benutzer root Passwort „mein Passwort“ und dann so etwas mit „Y“, „Y“, „Y“, (ungefähr ein Dutzend oder 15 Mal oder so) Allerdings kann ich diese Lösung nirgendwo finden Hilft mir hier jemand? Ich denke, es wäre so schön, wenn sie das einfach sagen würden in ihrer gesamten Dokumentation, anstatt es zu versuchen Verstecke es. Ich denke, das würde viele Probleme lösen. Nur set passwort = „Y“, „Y“, „Y“, es ist, als ob sie sich dafür schämen oder so. Gepostet von AJIT DIXIT am Montag, 25. November 2002, um 6:56 Uhr [Löschen] [Bearbeiten] Wenn ich mit dem Root-Benutzer an einem Multi-Table-Update arbeite es funktioniert gut Wenn ich mit einem Nicht-Root-Benutzer arbeite, erhalte ich eine Fehlermeldung SQL: Händler aktualisieren, Bereiche a_nm = aname festlegen wobei acd = Fläche

In diesem Kapitel erfahren Sie, wie Sie mit Privilegien arbeiten. Wie in Kapitel 2 besprochen, wird SQL typischerweise in Umgebungen verwendet, die eine Benutzererkennung und Unterscheidung zwischen verschiedenen Systembenutzern erfordern. Im Allgemeinen erstellen Datenbankadministratoren selbst Benutzer und erteilen ihnen Berechtigungen. Andererseits haben Benutzer, die selbst Tabellen erstellen, Rechte, diese Tabellen zu verwalten. Berechtigungen bestimmen, ob ein bestimmter Benutzer einen bestimmten Befehl ausführen kann. Es gibt verschiedene Arten von Berechtigungen, die verschiedenen Arten von Vorgängen entsprechen. Berechtigungen werden mit zwei SQL-Befehlen gewährt und widerrufen: - GRANT und REVOKE. In diesem Kapitel erfahren Sie, wie diese Befehle verwendet werden.

BENUTZER

Jeder Benutzer in einer SQL-Umgebung verfügt über einen speziellen Identifikationsnamen oder eine spezielle Identifikationsnummer. Die Terminologie ist überall unterschiedlich, aber wir haben uns (in Anlehnung an ANSI) dafür entschieden, sie oder die Nummer als Access Identifier (ID) zu bezeichnen. Ein an die Datenbank gesendeter Befehl ist einem bestimmten Benutzer zugeordnet; oder andernfalls eine spezielle Zugriffskennung. In Bezug auf eine SQL-Datenbank ist die Berechtigungs-ID der Benutzername, und SQL kann das spezielle Schlüsselwort USER verwenden, das sich auf die Zugriffs-ID bezieht, die dem aktuellen Befehl zugeordnet ist. Der Befehl wird basierend auf den Informationen, die mit der Zugriffs-ID des Benutzers verknüpft sind, der den Befehl ausgibt, interpretiert und zugelassen (oder verweigert).

ANMELDUNG

Bei Systemen mit zahlreichen Benutzern gibt es eine Art Anmeldevorgang, den der Benutzer durchführen muss, um Zugriff auf das Computersystem zu erhalten. Dieses Verfahren bestimmt, welche Zugriffs-ID dem aktuellen Benutzer zugeordnet wird. Normalerweise muss jede Person, die die Datenbank nutzt, über eine eigene Zugangs-ID verfügen und wird bei der Registrierung zu einem gültigen Benutzer. Allerdings können häufig Benutzer mit vielen Aufgaben unter verschiedenen Zugangs-IDs registriert werden, oder umgekehrt kann eine Zugangs-ID von mehreren Benutzern verwendet werden. Aus SQL-Sicht gibt es keinen Unterschied zwischen diesen beiden Fällen; Es behandelt den Benutzer einfach als seine Zugangs-ID. Die SQL-Datenbank verwendet möglicherweise ein eigenes Anmeldeverfahren oder ermöglicht ein anderes Programm, z Betriebssystem(das Hauptprogramm, das auf Ihrem Computer läuft), verarbeiten Sie die Registrierungsdatei und erhalten Sie die Zugangs-ID von diesem Programm. Auf die eine oder andere Weise verfügt SQL über eine Zugriffs-ID, die Sie Ihren Aktionen zuordnen können, und das Schlüsselwort USER ist für Sie relevant.

PRIVILEGIEN GEWÄHRLEISTEN

Jeder Benutzer in einer SQL-Datenbank verfügt über eine Reihe von Berechtigungen. Dies ist, was der Benutzer tun darf (vielleicht handelt es sich um eine Protokolldatei, was als Mindestprivileg angesehen werden kann). Diese Privilegien können sich im Laufe der Zeit ändern – neue werden hinzugefügt, alte entfernt. Einige dieser Berechtigungen sind in ANSI SQL definiert, es sind jedoch auch zusätzliche Berechtigungen erforderlich. Die von ANSI definierten SQL-Berechtigungen reichen in den meisten realen Situationen nicht aus. Andererseits können die Arten der erforderlichen Berechtigungen je nach Art des von Ihnen verwendeten Systems variieren – ANSI gibt hierfür keine Empfehlungen. Berechtigungen, die nicht Teil des SQL-Standards sind, verwenden möglicherweise eine ähnliche Syntax, die nicht vollständig mit dem Standard übereinstimmt.

STANDARD-PRIVILEGIEN

Von ANSI definierte SQL-Berechtigungen sind Objektberechtigungen. Dies bedeutet, dass der Benutzer das Recht hat, einen bestimmten Befehl nur für ein bestimmtes Objekt in der Datenbank auszuführen. Offensichtlich müssen Privilegien zwischen diesen Objekten unterscheiden, aber ein Privilegiensystem, das ausschließlich auf den Privilegien eines Objekts basiert, kann nicht alles abdecken, was SQL benötigt, wie wir später in diesem Kapitel sehen werden. Die Berechtigungen eines Objekts sind sowohl Benutzern als auch Tabellen zugeordnet. Das heißt, die Berechtigung wird einem bestimmten Benutzer in einer bestimmten Tabelle oder einer zugrunde liegenden Tabelle oder Ansicht gewährt. Sie müssen bedenken, dass der Benutzer, der die Tabelle (jeglicher Art) erstellt hat, der Eigentümer dieser Tabelle ist.

Das bedeutet, dass der Benutzer alle Rechte in dieser Tabelle hat und Privilegien auf andere Benutzer in dieser Tabelle übertragen kann. Berechtigungen, die einem Benutzer zugewiesen werden können:

SELECT Ein Benutzer mit dieser Berechtigung kann Abfragen für die Tabelle ausführen.

INSERT Ein Benutzer mit dieser Berechtigung kann einen INSERT-Befehl für eine Tabelle ausführen.

UPDATE Ein Benutzer mit dieser Berechtigung kann einen UPDATE-Befehl für eine Tabelle ausgeben. Sie können dieses Privileg auf bestimmte Tabellenspalten beschränken.

DELETE Ein Benutzer mit dieser Berechtigung kann einen DELETE-Befehl für eine Tabelle ausgeben.

REFERENZEN Ein Benutzer mit dieser Berechtigung kann einen Fremdschlüssel definieren, der eine oder mehrere Spalten dieser Tabelle als übergeordneten Schlüssel verwendet. Sie können dieses Privileg auf bestimmte Spalten beschränken. (Einzelheiten zu Fremdschlüssel und übergeordnetem Schlüssel finden Sie in Kapitel 19.)

Darüber hinaus werden Sie auf nicht standardmäßige Objektprivilegien stoßen, wie z. B. INDEX, das das Recht gibt, einen Index für eine Tabelle zu erstellen, SYNONYM, das das Recht gibt, ein Synonym für ein Objekt zu erstellen, was in Kapitel 23 erläutert wird. und ALTER, das das Recht gibt, den ALTER TABLE-Befehl für eine Tabelle auszuführen. Die SQL-Engine weist Benutzern diese Berechtigungen mithilfe des GRANT-Befehls zu.

GRANT-TEAM

Nehmen wir an, dass die Benutzerin Diane eine Customers-Tabelle hat und dem Benutzer Adrian erlauben möchte, diese abzufragen. Diane sollte dann den folgenden Befehl eingeben:

GEWÄHRLEISTUNG FÜR VERKÄUFER AN Diane;

Jetzt kann Adrian Abfragen für die Tabelle „Kunden“ ausführen. Ohne andere Privilegien kann er nur Werte auswählen; kann jedoch keine Aktion ausführen, die sich auf die Werte in der Kundentabelle auswirken würde (einschließlich der Verwendung der Kundentabelle als übergeordnete Tabelle des Fremdschlüssels, wodurch die Änderungen begrenzt werden, die am Wert in der Kundentabelle vorgenommen werden können).

Wenn SQL einen GRANT-Befehl empfängt, überprüft es die Berechtigungen des Benutzers, der den Befehl ausgibt, um festzustellen, ob der GRANT-Befehl gültig ist. Adrian kann diesen Befehl nicht alleine erteilen. Es kann auch keinem anderen Benutzer die SELECT-Berechtigung erteilen: Die Tabelle gehört immer noch Diane (wir werden später zeigen, wie Diane Adrian anderen Benutzern die SELECT-Berechtigung erteilen kann).

Die Syntax ist dieselbe wie für die Gewährung anderer Privilegien. Wenn Adrian der Eigentümer der Sellers-Tabelle ist, kann er Diane mithilfe der folgenden Klausel gestatten, darin Zeilen einzugeben

GEWÄHRLEISTUNG FÜR VERKÄUFER AN Diane; Diane hat nun das Recht, einen neuen Verkäufer in die Tabelle aufzunehmen.

PRIVILEGIENGRUPPEN, BENUTZERGRUPPEN

Sie sollten sich nicht darauf beschränken, einem einzelnen Benutzer mit dem GRANT-Befehl ein einzelnes Privileg zu gewähren. Durch Kommas getrennte Listen von Berechtigungen oder Benutzern sind vollkommen akzeptabel. Stephen kann für Adrian sowohl SELECT als auch INSERT in der Order-Tabelle bereitstellen

GRANT SELECT, INSERT ON Orders TO Adrian; oder für Adrian und Diane GRANT SELECT, INSERT ON Orders TO Adrian, Diane;

Wenn Berechtigungen und Benutzer auf diese Weise aufgelistet werden, wird die gesamte Liste der Berechtigungen allen angegebenen Benutzern gewährt. In der strengen ANSI-Interpretation können Sie nicht mit einem einzigen Befehl Berechtigungen für viele Tabellen gleichzeitig erteilen. Einige Implementierungen können diese Einschränkung jedoch lockern, indem Sie die Angabe mehrerer Tabellen, durch Kommas getrennt, ermöglichen, sodass die gesamte Liste der Berechtigungen für alle gewährt werden kann angegebenen Tabellen. .

BESCHRÄNKUNG DER PRIVILEGIEN AUF BESTIMMTE SPALTEN

Alle Objektberechtigungen verwenden dieselbe Syntax, mit Ausnahme der Befehle UPDATE und REGERNCES, die keine Spaltennamen erfordern. Das UPDATE-Privileg kann wie andere Privilegien gewährt werden:

Gewähren Sie Diane ein Update zu den Vertriebsmitarbeitern;

Mit diesem Befehl kann Diane die Werte in einer oder allen Spalten der Vendors-Tabelle ändern. Wenn Adrian Diane jedoch daran hindern möchte, beispielsweise Provisionen zu ändern, kann er eingeben

GEWÄHRLEISTUNG UPDATE (comm) ÜBER VERKÄUFER AN Diane;

Mit anderen Worten: Es muss lediglich die spezifische Spalte angegeben werden, auf die das UPDATE-Privileg angewendet werden soll, und zwar in Klammern nach dem Tabellennamen. Die Namen mehrerer Tabellenspalten können in beliebiger Reihenfolge, durch Kommas getrennt, angegeben werden:

GRANT UPDATE (Stadt, Kommunikation) über Verkäufer an Diane;

REFERENZEN folgt der gleichen Regel. Wenn Sie einem anderen Benutzer die REFERENCES-Berechtigung erteilen, kann dieser Fremdschlüssel erstellen, die als übergeordnete Schlüssel auf Spalten in Ihrer Tabelle verweisen. Wie UPDATE kann das REFERENCES-Privileg als Liste einer oder mehrerer Spalten angegeben werden, für die dieses Privileg eingeschränkt ist. Diane könnte Stephen beispielsweise mit dem folgenden Befehl das Recht erteilen, die Customer-Tabelle als übergeordnete Schlüsseltabelle zu verwenden:

Gewähren Sie Stephen Referenzen (cname, cnum) für Kunden; Dieser Befehl gibt Stephen das Recht, die Spalten cnum und cname als übergeordnete Schlüssel für alle Fremdschlüssel in seinen Tabellen zu verwenden. Stephen kann steuern, wie dies geschieht. Es kann (cname, cnum) oder in unserem Fall (cnum, cname) als zweispaltigen übergeordneten Schlüssel definieren, der durch einen Fremdschlüssel mit zwei Spalten in einer seiner eigenen Tabellen übereinstimmt. Oder es kann separate Fremdschlüssel erstellen, um sich individuell auf das Geschlecht zu beziehen und so sicherzustellen, dass Diane ein übergeordneter Schlüssel zugewiesen ist (siehe Kapitel 19).

Da es keine Einschränkungen hinsichtlich der Fremdschlüsselnummern gibt, muss es auf diesen übergeordneten Schlüsseln basieren und es muss zulässig sein, dass sich die übergeordneten Schlüssel verschiedener Fremdschlüssel überlappen.

Wie beim UPDATE-Privileg können Sie eine Liste von Spalten ausschließen und so zulassen, dass alle Spalten als übergeordnete Schlüssel verwendet werden. Adrian kann Diane mit dem folgenden Befehl das Recht dazu erteilen:

Gewähren Sie Diane Referenzen für Verkäufer;

Natürlich kann das Privileg nur für Spalten verwendet werden, die den durch die übergeordneten Schlüssel erforderlichen Einschränkungen unterliegen.

ALLE UND ÖFFENTLICHEN ARGUMENTE VERWENDEN

SQL unterstützt zwei Argumente für den GRANT-Befehl, die eine besondere Bedeutung haben: ALL PRIVILEGES oder einfach ALL und PUBLIC. ALL wird anstelle von Privilegiennamen im GRANT-Befehl verwendet, um alle Privilegien in einer Tabelle zu gewähren. Diane könnte Stephen beispielsweise mit dem folgenden Befehl den gesamten Satz an Berechtigungen in der Tabelle „Kunden“ erteilen:

Gewähren Sie Diane Referenzen für Verkäufer;

(Die UPDATE- und REFERENCES-Berechtigungen gelten natürlich für alle Spalten.) Hier ist eine andere Möglichkeit, dasselbe auszudrücken:

GEWÄHREN SIE ALLES FÜR KUNDEN AN Stephen;

PUBLIC ähnelt eher einem Sammelargumenttyp als einem Benutzerprivileg. Wenn Sie Veröffentlichungsrechte gewähren, erhalten alle Benutzer diese automatisch. Am häufigsten wird dies für die SELECT-Berechtigung für bestimmte zugrunde liegende Tabellen oder Ansichten verwendet, die Sie jedem Benutzer zur Verfügung stellen möchten. Damit jeder Benutzer die Bestelltabelle sehen kann, können Sie beispielsweise Folgendes eingeben:

GEWÄHREN SIE AUSWAHL AUF BESTELLUNGEN AN DIE ÖFFENTLICHKEIT;

Natürlich können Sie der Gesellschaft einige oder alle Privilegien gewähren, aber das ist wahrscheinlich nicht ratsam. Alle Privilegien außer SELECT ermöglichen es dem Benutzer, den Inhalt der Tabelle zu ändern (oder, im Fall von REFERENCES, einzuschränken). Wenn Sie allen Benutzern erlauben, den Inhalt Ihrer Tabellen zu ändern, entsteht ein Problem.

Selbst wenn Sie ein kleines Unternehmen haben und alle Ihre aktuellen Benutzer in der Lage sind, Änderungsbefehle für eine bestimmte Tabelle auszuführen, wäre es besser, jedem Benutzer einzeln Berechtigungen zu erteilen, als allen dieselben Berechtigungen zu gewähren. PUBLIC ist nicht darauf beschränkt, es nur an aktuelle Benutzer zu übertragen. Beliebig Neuer Benutzer Eine zu Ihrem System hinzugefügte Datei erhält automatisch alle Berechtigungen, die zuvor allen zugewiesen wurden. Wenn Sie also jetzt oder in Zukunft den Zugriff auf die Tabelle auf alle beschränken möchten, ist es am besten, einzelnen Benutzern andere Berechtigungen als SELECT zu gewähren.

GEWÄHRUNG VON PRIVILEGIEN MIT DER GRANT-OPTION

Manchmal möchte der Ersteller einer Tabelle, dass andere Benutzer Berechtigungen für seine Tabelle erhalten. Dies geschieht typischerweise in Systemen, in denen eine oder mehrere Personen mehrere (oder alle) Basistabellen in einer Datenbank erstellen und dann die Verantwortung dafür an diejenigen delegieren, die tatsächlich mit ihnen arbeiten. SQL ermöglicht Ihnen dies mithilfe der WITH GRANT OPTION-Klausel. Wenn Diane wollte, dass Adrian anderen Benutzern die SELECT-Berechtigung für die Customers-Tabelle gewähren kann, würde sie ihm die SELECT-Berechtigung mithilfe der WITH GRANT OPTION-Klausel erteilen:

Gewähren Sie Adrian eine Auswahl an Kunden mit der Option „Gewähren“; Adrian erwarb daraufhin das Recht, das SELECT-Privileg an Dritte zu übertragen; es kann den Befehl GRANT SELECT ON Diane.Customers TO Stephen ausgeben; oder sogar GRANT SELECT ON Diane.Customers TO Stephen WITH GRANT OPTION; Ein Benutzer mit einer GRANT OPTION für eine bestimmte Berechtigung für eine bestimmte Tabelle kann diese Berechtigung für dieselbe Tabelle wiederum jedem anderen Benutzer mit oder ohne GRANT OPTION erteilen. Dadurch wird der Besitz der Tabelle selbst nicht geändert; Nach wie vor gehört die Tabelle ihrem Ersteller. (Daher müssen berechtigte Benutzer beim Verweisen auf diese Tabellen die Eigentümerzugriffs-ID voranstellen. Das nächste Kapitel zeigt Ihnen diese Methode.) Ein Benutzer, der die GRANT OPTION für alle Berechtigungen für eine bestimmte Tabelle verwendet, verfügt über die volle Berechtigung für diese Tabelle.

STORNIERUNG VON PRIVILEGIEN

So wie ANSI den Befehl CREATE TABLE zum Erstellen einer Tabelle anstelle des Befehls DROP TABLE zum Entfernen bereitstellt, können Sie mit dem Befehl GRANT Benutzern Berechtigungen erteilen, ohne eine Möglichkeit bereitzustellen, diese wieder zurückzunehmen. Die Notwendigkeit, Berechtigungen zu entfernen, ist auf den REVOKE-Befehl zurückzuführen, bei dem es sich eigentlich um ein Standardtool mit einer ziemlich klaren Eingabeform handelt. Die Syntax des REVOKE-Befehls ähnelt der von GRANT, hat jedoch die entgegengesetzte Bedeutung. Um das INSERT-Privileg für Adrian in der Order-Tabelle zu entfernen, können Sie eingeben

WIDERRUFEN SIE EINFÜGEN AUF Bestellungen VON Adrian;

Die Verwendung von Privilegien- und Benutzerlisten ist hier wie bei GRANT erlaubt, daher können Sie den folgenden Befehl eingeben:

REVOKE INSERT, DELETE ON Customers VON Adrian, Stephen; Allerdings gibt es hier einige Unklarheiten. Wer hat das Recht, Privilegien zu widerrufen? Wann verliert ein Benutzer, der das Recht hat, Berechtigungen auf andere zu übertragen, dieses Recht? Werden die Benutzer, denen er diese Privilegien gewährt hat, diese auch verlieren? Da es sich hierbei nicht um eine Standardfunktion handelt, gibt es keine verbindlichen Antworten auf diese Fragen. Der gebräuchlichste Ansatz ist jedoch dieser: * Berechtigungen werden von dem Benutzer widerrufen, der sie gewährt hat, und der Widerruf erfolgt kaskadierend, d. h. er wird automatisch an ihn weitergegeben alle Benutzer, die das Privileg von ihm erhalten haben.

VERWENDEN VON ANSICHTEN ZUM FILTERN VON PRIVILEGIEN

Durch die Verwendung von Ansichten können Sie Berechtigungsaktionen präziser gestalten. Immer wenn Sie einem Benutzer eine Berechtigung für eine Basistabelle gewähren, wird diese automatisch an alle Zeilen und, bei Verwendung der möglichen UPDATE- und REFERENCES-Ausnahmen, an alle Spalten der Tabelle weitergegeben. Indem Sie eine Ansicht erstellen, die auf die zugrunde liegende Tabelle verweist und die Berechtigung dann auf die Ansicht und nicht auf die Tabelle überträgt, können Sie diese Berechtigungen auf alle Ausdrücke in der in der Ansicht enthaltenen Abfrage beschränken. Dadurch werden die Grundfunktionen des GRANT-Befehls erheblich verbessert.

WER KANN EINREICHUNGEN EINREICHEN?

Um eine Ansicht zu erstellen, müssen Sie über SELECT-Berechtigungen für alle Tabellen verfügen, auf die Sie in der Ansicht verweisen. Wenn die Ansicht änderbar ist, werden alle INSERT-, UPDATE- und DELETE-Berechtigungen, die Sie für die Basistabelle haben, automatisch auf die Ansicht übertragen. Wenn Sie keine Änderungsrechte für die Basistabellen haben, können Sie diese nicht für die von Ihnen erstellten Ansichten haben, selbst wenn diese Ansichten selbst änderbar sind. Da in Ansichten keine Fremdschlüssel verwendet werden, wird das REFERENCES-Privileg beim Erstellen von Ansichten nie verwendet. Alle diese Einschränkungen werden von ANSI definiert. Es können auch nicht standardmäßige Systemberechtigungen (später in diesem Kapitel besprochen) aktiviert werden. In den folgenden Abschnitten gehen wir davon aus, dass die Ersteller der von uns besprochenen Ansichten über private oder entsprechende Berechtigungen für alle zugrunde liegenden Tabellen verfügen.

EINSCHRÄNKUNG DER SELECT-PRIVILEGE AUF BESTIMMTE SPALTEN

Angenommen, Sie möchten der Benutzerin Claire die Möglichkeit geben, nur die Spalten „snum“ und „sname“ der Tabelle „Sales“ anzuzeigen. Sie können dies tun, indem Sie die Namen dieser Spalten in die Ansicht einfügen

ERSTELLEN SIE ANSICHT Clairesview ALS AUSWÄHLEN snum, sname VON Verkäufern; und gewähren Sie Claire das SELECT-Privileg für die Ansicht und nicht für die Sellers-Tabelle selbst: GRANT SELECT On Clairesview to Claire; Sie können Berechtigungen wie andere Berechtigungen speziell für Spalten erstellen, aber bei einem INSERT-Befehl werden dadurch Standardwerte eingefügt, und bei einem DELETE-Befehl hat die Spaltenbeschränkung keine Auswirkung. Die REFERENCES- und UPDATE-Berechtigungen können natürlich Spalten spezifisch machen, ohne auf eine Ansicht zurückgreifen zu müssen.

EINSCHRÄNKUNG DER PRIVILEGIEN FÜR BESTIMMTE STREICHEN Normalerweise besteht eine sinnvollere Methode zum Filtern von Berechtigungen mit Ansichten darin, mithilfe der Ansicht festzulegen, dass die Berechtigung nur für bestimmte Zeilen gilt. Dies erreichen Sie auf natürliche Weise, indem Sie ein Prädikat für die Ansicht verwenden, das bestimmt, welche Zeilen enthalten sind. Um dem Benutzer Adrian die UPDATE-Berechtigung für die Kundentabelle für alle in London ansässigen Kunden zu erteilen, könnten Sie eine Ansicht wie diese erstellen:

CREATE VIEW Londoncust AS SELECT * FROM Customers WHERE city = „London“ WITH CHECK OPTION; Anschließend müssen Sie Adrian das UPDATE-Privileg für diese Tabelle erteilen: GRANT UPDATE ON Londoncust TO Adrian; Dies ist der Unterschied zwischen der Berechtigung für bestimmte Zeilen und der Berechtigung UPDATE für bestimmte Spalten, die für alle Spalten der Tabelle „Kunden“ gilt, jedoch nicht für Zeilen, bei denen Zeilen mit einem anderen Stadt-Geschlechtswert als London nicht berücksichtigt werden . Die WITH CHECK OPTION-Klausel verhindert, dass Adrian den Geschlechtswert der Stadt in etwas anderes als London ändert. GEWÄHRLEISTUNG DES ZUGRIFFS NUR AUF EXTRAHIERTE DATEN Eine andere Möglichkeit besteht darin, Benutzern Zugriff auf die bereits abgerufenen Daten und nicht auf die tatsächlichen Werte in der Tabelle zu gewähren. Aggregatfunktionen können bei der Verwendung dieser Methode sehr praktisch sein. Sie können eine Ansicht erstellen, die die Anzahl, den Durchschnitt und die Gesamtsumme der Bestellungen für jeden Tag der Bestellung anzeigt: CREATE VIEW Datetotals AS SELECT odate, COUNT (*), SUM (amt), AVG (amt) FROM Orders GROUP BY odate; Sie gewähren der Benutzerin Diane nun die SELECT-Berechtigung für die Datetotals-Ansicht: GRANT SELECT ON Datetotals TO Diane; VERWENDUNG VON DARSTELLUNGEN ALS ALTERNATIVE ZU EINSCHRÄNKUNGEN Eine der neuesten Anwendungen der Reihe, die in Kapitel 18 beschrieben wird, ist die Verwendung von Ansichten mit WITH CHECK OPTION als Alternative zu Einschränkungen. Angenommen, Sie möchten sicherstellen, dass sich alle Geschlechtswerte für Städte in der Tabelle „Lieferanten“ in einer der Städte befinden, in denen Ihr Unternehmen derzeit eine Niederlassung hat. Sie können eine CHECK-Einschränkung direkt in der Stadtspalte festlegen. Es kann jedoch schwierig werden, diese später zu ändern, wenn Ihr Unternehmen dort beispielsweise andere Abteilungen eröffnet. Alternativ können Sie eine Ansicht erstellen, die ungültige Stadtwerte ausschließt: CREATE VIEW Curcities AS SELECT * FROM Salespeople WHERE city IN ("London", "Rome", "San Jose", "Berlin") WITH CHECK OPTION; Anstatt Benutzern jetzt Änderungsrechte in der Tabelle „Händler“ zu erteilen, können Sie ihnen nun in der Ansicht „Währungen“ gewähren. Der Vorteil dieses Ansatzes besteht darin, dass Sie, wenn Sie eine Änderung vornehmen müssen, diese Ansicht löschen, eine neue erstellen und Benutzern in dieser neuen Ansicht Berechtigungen erteilen können, was einfacher ist als das Ändern von Einschränkungen. Der Nachteil besteht darin, dass der Eigentümer der Sales-Tabelle auch diese Ansicht verwenden muss, wenn er nicht möchte, dass seine eigenen Befehle abgelehnt werden. Andererseits ermöglicht dieser Ansatz dem Tabelleneigentümer und allen anderen, Änderungsrechte für die Tabelle selbst und nicht für die Ansicht zu erlangen, um Ausnahmen von Einschränkungen zu machen.

Dies ist oft wünschenswert, aber nicht machbar, wenn Sie Einschränkungen für die Basistabelle verwenden. Leider sind diese Ausnahmen in der Ansicht nicht sichtbar. Wenn Sie diesen Ansatz wählen, möchten Sie eine zweite Ansicht erstellen, die nur Ausnahmen enthält: CREATE VIEW Othercities AS SELECT * FROM Salespeople WHERE city NOT IN („London“, „Rome“, „San Jose“, „Berlin“) WITH OPTION PRÜFEN; Sie sollten Benutzern nur die SELECT-Berechtigung für diese Ansicht gewähren, damit sie die ausgeschlossenen Zeilen sehen können, aber keine ungültigen Stadtwerte in die zugrunde liegende Tabelle einfügen können. Tatsächlich könnten Benutzer beide Ansichten in einer Union abfragen und alle Zeilen gleichzeitig sehen.

ANDERE ARTEN VON PRIVILEGIEN

Natürlich möchten Sie zuerst wissen, wer das Recht hat, die Tabelle zu erstellen. Dieser Privilegienbereich ist kein ANSI, kann aber nicht ignoriert werden. Alle standardmäßigen ANSI-Berechtigungen leiten sich von dieser Berechtigung ab; Privilegien von Tabellenerstellern, die Objektprivilegien übertragen können. Wenn alle Ihre Benutzer Basistabellen im System erstellen mit verschiedene Größen Dies führt zu einer Redundanz und zu einer Ineffizienz des Systems. Auch andere Fragen erregen Aufmerksamkeit:

Wer hat das Recht, Tabellen zu ändern, zu löschen oder einzuschränken?

Sollten sich die Rechte zum Erstellen von Basistabellen von den Rechten zum Erstellen von Ansichten unterscheiden?

Sollte es einen Superuser geben – einen Benutzer, der für die Pflege der Datenbank verantwortlich ist und daher über die meisten oder alle Berechtigungen verfügt, die nicht einzeln gewährt werden?

Solange ANSI nicht beteiligt ist und SQL in verschiedenen Umgebungen verwendet wird, können wir keine endgültige Antwort auf diese Fragen geben. Wir schlagen vor, hier einen Teil der allgemeinsten Schlussfolgerungen zu betrachten.

Berechtigungen, die nicht in Bezug auf spezielle Datenobjekte definiert sind, werden als Systemprivilegien oder Datenbankrechte bezeichnet. Auf einer grundlegenden Ebene umfassen diese wahrscheinlich das Recht, Datenobjekte zu erstellen, wahrscheinlich andere als Basistabellen (normalerweise von einigen wenigen Benutzern erstellt) und Ansichten (normalerweise von der Mehrheit der Benutzer erstellt). Systemprivilegien zum Erstellen von Ansichten sollten zusätzlich zu den Objektprivilegien gelten und diese nicht ersetzen, die ANSI von den Erstellern von Ansichten verlangt (weiter oben in diesem Kapitel beschrieben). Darüber hinaus gibt es in einem System jeder Größe immer einige Arten von Superusers – Benutzer, die automatisch über die meisten oder alle Privilegien verfügen – und die ihren Superuser-Status über ein Privileg oder eine Gruppe von Privilegien auf eine andere Person übertragen können. Datenbankadministrator oder DBA ist der am häufigsten verwendete Begriff für einen solchen Superuser und die Berechtigungen, die er hat.

TYPISCHE SYSTEMPRIVILEGIEN

Im Allgemeinen gibt es drei grundlegende Systemrechte: - CONNECT, - RESOURCE und - DBA (Datenbankadministrator). Vereinfacht ausgedrückt besteht CONNECT aus dem Recht zur Registrierung und dem Recht zum Erstellen von Ansichten und Synonymen (siehe Kapitel 23), wenn die Privilegien des Objekts übergeben werden. RESSOURCE besteht aus dem Recht, Basistabellen zu erstellen. DBA ist eine Superuser-Berechtigung, die dem Benutzer hohe Berechtigungen in der Datenbank verleiht. Ein oder mehrere Benutzer mit Datenbankadministratorfunktionen können über diese Berechtigung verfügen. Einige Systeme haben auch einen speziellen Benutzer, manchmal SYSADM oder SYS (System Database Administrator) genannt, der über die höchste Autorität verfügt; Es ist etwas Besonderes für sie und nicht nur für einen Benutzer mit besonderen DBA-Berechtigungen. Tatsächlich darf sich nur eine Person mit dem Namen SYSADM, der ihre Zugangs-ID ist, registrieren. Die Unterscheidung ist recht subtil und funktioniert in verschiedenen Systemen unterschiedlich. Für unsere Zwecke beziehen wir uns auf einen hochprivilegierten Benutzer, der eine Datenbank mit DBA-Privilegien entwickelt und verwaltet, wobei wir uns darüber im Klaren sind, dass es sich bei diesen Privilegien tatsächlich um dieselben Privilegien handelt. Der GRANT-Befehl ist in modifizierter Form sowohl mit Objektprivilegien als auch mit Systemprivilegien verwendbar. Die Rechteübertragung kann zunächst über einen DBA erfolgen. Beispielsweise könnte ein DBA Rodriguez die Berechtigung zum Erstellen von Tabellen wie folgt erteilen: GRANT RESOURCE TO Rodriguez;

Benutzer erstellen und löschen

Natürlich stellt sich die Frage: Woher kommt ein Benutzer namens Rodriguez? Wie ermittelt man die Freigabe-ID? In den meisten Implementierungen erstellt der DBA den Benutzer, indem er ihm automatisch die CONNECT-Berechtigung gewährt. In diesem Fall wird normalerweise eine IDENTIFIED BY-Klausel hinzugefügt, um das Passwort anzugeben. (Wenn nicht, muss das Betriebssystem feststellen, ob Sie sich mit der angegebenen Zugriffs-ID bei der Datenbank anmelden können.) Der DBA könnte beispielsweise GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon ausgeben; Dadurch wird ein Benutzer namens Thelonius erstellt, ihm das Recht zur Registrierung erteilt und ihm das Passwort Redwagon zugewiesen – alles in einem Satz. Da Thelonious bereits ein authentifizierter Benutzer ist, kann er oder der DBA denselben Befehl verwenden, um das Passwort von Redwagon zu ändern. Obwohl dies praktisch ist, weist dieser Ansatz dennoch Einschränkungen auf. Dies ist die Unmöglichkeit, einen Benutzer zu haben, der sich zumindest vorübergehend nicht registrieren konnte. Wenn Sie verhindern möchten, dass sich ein Benutzer anmeldet, müssen Sie die CONNECT-Berechtigung für REVOKE verwenden, wodurch dieser Benutzer „entfernt“ wird. Bei einigen Implementierungen können Sie Benutzer unabhängig von ihren Anmelderechten erstellen und löschen. Wenn Sie einem Benutzer die CONNECT-Berechtigung erteilen, erstellen Sie diesen Benutzer. Um dies selbst tun zu können, müssen Sie darüber hinaus über DBA-Berechtigungen verfügen. Wenn dieser Benutzer Basistabellen (nicht nur Ansichten) erstellen soll, muss ihm auch die Berechtigung RESOURCE gewährt werden. Doch daraus ergibt sich sofort ein weiteres Problem. Wenn Sie versuchen, die CONNECT-Berechtigung eines Benutzers zu entfernen, der über von ihm erstellte Tabellen verfügt, wird der Befehl abgelehnt, da die Tabelle dadurch keinen Eigentümer mehr hätte, was nicht zulässig ist. Sie müssen zunächst alle von diesem Benutzer erstellten Tabellen löschen, bevor Sie ihm die CONNECT-Berechtigung entziehen. Wenn diese Tabellen nicht leer sind, möchten Sie ihre Daten wahrscheinlich mit dem INSERT-Befehl, der eine Abfrage verwendet, an andere Tabellen übergeben. Sie müssen das RESOURSE-Privileg nicht separat entfernen; Es reicht aus, CONNECT zu löschen, um den Benutzer zu löschen. Obwohl es sich bei dem oben genannten Ansatz um einen ziemlich standardmäßigen Ansatz für Systemprivilegien handelt, weist er auch erhebliche Einschränkungen auf. Es sind alternative Ansätze entstanden, die spezifischer definiert sind und Systemprivilegien genauer steuern.

Diese Schlussfolgerungen gehen etwas über den derzeit definierten SQL-Standard hinaus und gehen in einigen Implementierungen möglicherweise sogar vollständig über den SQL-Standard hinaus. Diese Dinge werden Sie wahrscheinlich nicht allzu sehr beschäftigen, es sei denn, Sie sind DBA oder Benutzer hohes Level. Normale Benutzer müssen lediglich mit den grundsätzlichen Berechtigungen des Systems vertraut sein und nur bei speziellen Meldungen deren Dokumentation konsultieren.

ZUSAMMENFASSUNG

Berechtigungen geben Ihnen die Möglichkeit, SQL aus einer neuen Perspektive zu betrachten, wenn SQL Aktionen über spezielle Benutzer auf einem speziellen Datenbanksystem ausführt. Der GRANT-Befehl selbst ist recht einfach: Mit seiner Hilfe gewähren Sie einem oder mehreren Benutzern bestimmte Privilegien eines Objekts. Wenn Sie einem Benutzer die Berechtigung WITH GRANT OPTION gewähren, kann dieser Benutzer diese Berechtigung wiederum anderen gewähren. Sie verstehen jetzt die Hinweise zur Verwendung von Berechtigungen für Ansichten – zur Erweiterung der Berechtigungen in Basistabellen oder als Alternative zu Einschränkungen – und einige der Vor- und Nachteile dieses Ansatzes. Systemrechte, die erforderlich sind, aber nicht im Rahmen des SQL-Standards liegen, wurden in ihrer allgemeinsten Form besprochen und können daher durch Übung erlernt werden. In Kapitel 23 wird die Diskussion über Inferenz in SQL fortgesetzt, z. B. das Speichern oder Wiederherstellen von Änderungen, das Erstellen eigener Namen für Tabellen, die anderen Personen gehören, und das Verstehen, was passiert, wenn verschiedene Benutzer gleichzeitig versuchen, auf dasselbe Objekt zuzugreifen.

ARBEITEN MIT SQL

1. Geben Sie Janet das Recht, die Bewertung des Kunden zu ändern.

2. Geben Sie Stephan das Recht, anderen Benutzern das Recht zu gewähren, Abfragen in der Tabelle „Bestellungen“ durchzuführen.

3. Entfernen Sie das INSERT-Privileg in der Vendors-Tabelle von Claire und allen Benutzern, denen es gewährt wurde.

4. Geben Sie Jerry das Recht, die Tabelle „Kunden“ einzufügen oder zu ändern, während seine Fähigkeit zur Auswertung von Werten im Bereich von 100 bis 500 erhalten bleibt.

5. Erlauben Sie Janet, die Kundentabelle abzufragen, aber verhindern Sie, dass sie die Bewertungen in derselben Kundentabelle verringert.

Die SQL Server-Plattform verwendet die REVOKE-Anweisung als Möglichkeit, die einem bestimmten Benutzer zugewiesenen Berechtigungseinstellungen zu widerrufen. Dieser Punkt ist wichtig, da SQL Server eine zusätzliche DENY-Anweisung unterstützt, die einem Benutzer explizit den Zugriff auf eine angegebene Ressource verweigert. In SQL Server kann die REVOKE-Anweisung verwendet werden, um einem Benutzer mithilfe der GRANT-Anweisung zugewiesene Berechtigungen zu widerrufen. Wenn Sie einem Benutzer explizit ein bestimmtes Privileg verweigern möchten, sollten Sie die DENY-Anweisung verwenden.

Die SQL Server-Plattform unterstützt die Klauseln ANSI HIERARCHY OPTION und ADMIN OPTION nicht. Obwohl die ADMIN OPTION-Klausel nicht unterstützt wird, verfügt die SQL Server-Version des REVOKE-Befehls über zwei Administratorrechte (CREATE und BACKUP). Die Befehlssyntax lautet wie folgt.

REVOKE ([object_privileg] [, ...] | [system_privileg]) [(column [, ...])]]| (TO | FROM) (recipient_name [, …] | Rolle [, …] | PUBLIC | GUEST) ]

OPTION GEWÄHREN FÜR

Dem Benutzer wird das Recht entzogen, anderen Benutzern bestimmte Privilegien zuzuweisen.

Objektprivileg

Zugriffsrechte auf verschiedene Anweisungen, die in beliebiger Reihenfolge kombiniert werden können, werden widerrufen.

ALLE

Alle in zugewiesenen Berechtigungen momentan angegebene Benutzer und/oder für angegebene Datenbankobjekte. Von diesem Vorschlag wird abgeraten, da er die Mehrdeutigkeit der Programmierung fördert.

(AUSWÄHLEN | EINFÜGEN, LÖSCHEN, UPDATE)

Dem angegebenen Benutzer wird die angegebene Zugriffsberechtigung für das angegebene Objekt (z. B. eine Tabelle oder Ansicht) verweigert. Um Berechtigungen auf Spaltenebene zu widerrufen, verwenden Sie eine in Klammern eingeschlossene Liste von Spalten.

VERWEISE

Das Recht zum Erstellen und Löschen von Fremdschlüsseleinschränkungen, die auf ein Datenbankobjekt als übergeordnetes Objekt verweisen, wird widerrufen.

Das Recht des Benutzers, eine Regel in einer Tabelle oder Ansicht zu erstellen oder zu löschen, wird widerrufen.

Das Recht zum Ausführen einer gespeicherten Prozedur, einer benutzerdefinierten Funktion oder einer erweiterten gespeicherten Prozedur wird widerrufen.

Systemprivileg

Das Recht zur Ausführung der folgenden Anweisungen wird widerrufen: CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLE, CREATE VIEW, BACKUP DATABASE und BACKUP LOG.

ON [Objekt] [(Spalte [, ...])]

Das Zugriffsrecht des Benutzers auf das angegebene Objekt wird widerrufen. Wenn es sich bei dem Objekt um eine Tabelle oder Ansicht handelt, können Sie Zugriffsrechte für einzelne Spalten entziehen. Sie können die Berechtigungen SELECT, INSERT, UPDATE, DELETE und REFERENCES für eine Tabelle oder Ansicht widerrufen. Für Tabellen- oder Ansichtsspalten können Sie nur die SELECT- und UPDATE-Berechtigungen widerrufen. Sie können EXECUTE-Berechtigungen in einer gespeicherten Prozedur, einer benutzerdefinierten Funktion oder einer erweiterten gespeicherten Prozedur widerrufen.

[ZU | VON] Empfängername | Rolle | ÖFFENTLICH | GAST

Gibt die Benutzer oder Rollen an, die die angegebene Berechtigung verlieren. Sie können das Schlüsselwort PUBLIC verwenden, um der Rolle PUBLIC (die alle Benutzer umfasst) zugewiesene Berechtigungen zu entziehen. Sie können mehrere Empfänger auflisten und ihre Namen durch Kommas trennen. Wird auch in SQL Server unterstützt Konto GUEST, der von allen Benutzern verwendet wird, die keinen eigenen Eintrag in der Datenbank haben.

Die Privilegien von Benutzern, die ihre Rechte durch die WITH GRANT OPTION-Klausel erhalten haben, werden entfernt. Diese Klausel ist erforderlich, wenn die GRANT OPTION FOR-Klausel verwendet wird.

AS (Gruppenname Rollenname)

Die Rechte, unter denen das Privileg widerrufen wird, sind angegeben. In manchen Fällen benötigt ein Benutzer möglicherweise vorübergehend die Rechte einer bestimmten Gruppe, um die angegebenen Berechtigungen außer Kraft zu setzen. In diesem Fall können Sie die AS-Klausel nutzen, um solche Rechte zu erlangen.

Die beiden Formen der REVOKE-Anweisung, REVOKE-Objektprivileg und REVOKE-Systemprivileg, schließen sich gegenseitig aus. Versuchen Sie nicht, beide Operationen in einer Anweisung auszuführen. Der wesentliche syntaktische Unterschied zwischen den beiden besteht darin, dass Sie die ON-Klausel nicht verwenden sollten, wenn Sie Systemrechte entfernen. Um beispielsweise ein Systemprivileg zu entfernen, können Sie den folgenden Befehl verwenden.

Widerrufen Sie die Erstellung einer Datenbank und sichern Sie eine Datenbank von Dylan, Katie

Wenn einem Benutzer mithilfe der WITH GRANT OPTION-Klausel Berechtigungen zugewiesen wurden, sollten diese Berechtigungen durch die gleichzeitige Verwendung von zwei Klauseln widerrufen werden – WITH GRANT OPTION und CASCADE. Zum Beispiel:

REVOKE GRANT OPTION FOR SELECT, INSERT, UPDATE, DELETE ON titles TO editors CASCADE GO

Der REVOKE-Befehl kann nur für die aktuelle Datenbank verwendet werden. Dementsprechend werden die ANSI-Standardoptionen CURRENTJJSER und CURRENTROLE immer implizit vorausgesetzt. Die REVOKE-Anweisung wird auch zum Aufheben aller DENY-Optionen verwendet.

Die SQL Server-Plattform unterstützt auch eine zusätzliche DENY-Anweisung. Die Syntax der DENY-Anweisung ist identisch mit der Syntax der REVOKE-Anweisung. Im Wesentlichen unterscheiden sie sich jedoch dadurch, dass REVOKE die Privilegien des Benutzers neutralisiert, während DENY sie ausdrücklich verbietet. Verwenden Sie die DENY-Anweisung, um einem Benutzer oder einer Rolle den Zugriff auf eine Berechtigung zu verweigern, selbst wenn die Berechtigung explizit oder durch Rollenzuweisung gewährt wird.

Die REVOKE-Anweisung muss verwendet werden, um zuvor gewährte oder DENY-Berechtigungen zu entfernen. Beispielsweise ging Benutzerin Kelly in einen verlängerten Mutterschaftsurlaub. Während dieser Zeit wurde ihr der Zugang zum Mitarbeitertisch verweigert. Sie kehrte zurück und wir gewährten ihr wieder Privilegien.

VERWEIGERN SIE ALLES, UM Kelly GEHEN zu lassen

WIDERRUFEN SIE ALLE MITARBEITER AN Kelly GO

In diesem Beispiel entfernt der REVOKE-Befehl ihre Berechtigungen nicht; er überschreibt den DENY-Befehl.

Durch das Erstellen eines Benutzers erhält der Benutzer an sich keine Rechte zum Zugriff auf Datenbankobjekte.

Berechtigungen werden durch den GRANT-Befehl erteilt. Es ist zu beachten, dass der Benutzer, der den GRANT-Befehl ausgibt, nur die Rechte übertragen oder, wenn Sie es vorziehen, an andere Benutzer delegieren kann, über die er selbst verfügt.

GRANT legt Rechte an Datenbankobjekten für Benutzer, Rollen oder andere Datenbankobjekte fest. Wenn ein Objekt erstellt wird, hat nur sein Ersteller Rechte daran und nur er kann anderen Benutzern oder Objekten Rechte gewähren.

Um auf eine Tabelle oder Ansicht zuzugreifen, benötigt der Benutzer oder das Objekt die Rechte SELECT, INSERT, UPDATE, DELETE oder REFERENCES. Mit der Option ALL können alle Rechte vergeben werden.

Um eine Prozedur in einer Anwendung aufzurufen, muss der Benutzer über EXECUTE-Rechte verfügen.

Benutzer können die Erlaubnis erhalten, anderen Benutzern Rechte zu gewähren, indem sie Rechte gemäß der Liste übertragen , die durch die Option WITH GRANT OPTION angegeben wird. Der Nutzer kann anderen nur die Rechte einräumen, die ihm selbst zustehen.

Berechtigungen können allen Benutzern erteilt werden, indem die Option PUBLIC anstelle der Liste der Benutzernamen verwendet wird. Die Angabe der Option PUBLIC wirkt sich nur auf Benutzer aus, nicht auf Datenbankobjekte.

Die Liste der Rechte ist in der Tabelle aufgeführt. 8.5.

Tabelle 8.5. Liste der Rechte

Rechte können von dem Benutzer, der sie gewährt hat, mit dem REVOKE-Befehl widerrufen werden. Wenn Rechte mit ALL ausgegeben wurden, können sie nur im ALL-Modus aufgelöst werden. Wenn Rechte mit PUBLIC ausgegeben wurden, können sie nur im PUBLIC-Modus aufgelöst werden.

Syntax:

GRANT (alle /PRIVILEGES] / LJST_ ) AUF DEM TISCH ]

(Tabellenname/Ansichtsname)

ZU(