6.3 GRANT und REVOKE

6 Sicherheitsregeln
6. Man beachte, daß beispielsweise die UPDATE-Anweisung UPDATE T SET C =
1 ... das Recht UPDATE auf der Spalte C der Tabelle T erfordert, wohingegen
(beispielsweise) die UPDATE-Anweisung UPDATE T SET C = T, C + 1 ... aufgrund der Spaltenreferenz T.C auch das Recht SELECT auf T erfordert.
6.3
GRANT und REVOKE
Wie bereits erwähnt, werden dem Eigentümer eines Objekts automatisch alle Rechte
gewährt, die für dieses Objekt Sinn machen. Außerdem werden diese Rechte mit der
GRANT-Option (Option auf Weitergabe von Rechten) gewährt. Wird ein Recht mit
der GRANT-Option gewährt, meine ich im allgemeinen, daß der Empfänger des
Rechts dafür die Berechtigung zur Rechtevergabe (grant autority, kein Begriff im
Standard) hat. Das bedeutet, daß der Empfänger wiederum dasselbe Recht (mit oder
ohne GRANT-Option) an andere Benutzer vergeben kann und so weiter.
Die Rechtevergabe erfolgt mittels der Anweisung GRANT, die unten im einzelnen
besprochen wird. So kann der Eigentümer eines Objekts die GRANT-Anweisung
verwenden, um Rechte an diesem Objekt an andere Benutzer zu vergeben; weiterhin
kann eine solche GRANT-Anweisung optional die Angabe WITH GRANT OPTION
enthalten – falls ja, kann der Empfänger dasselbe Recht an einen Dritten weitergeben
etc.
Hinweis: GRANT (wie auch CREATE DOMAIN, CREATE TABLE etc.) kann auch
als unabhängige, eigenständige Operationen ausgeführt werden, oder sie kann innerhalb einer CREATE SCHEMA-Anweisung als Schema-Element ausgeführt werden.
REVOKE muß als unabhängige Operation ausgeführt werden.
Es sei bemerkt, daß man sich GRANT und REVOKE logisch als »CREATE
AUTHORIZATION« beziehungsweise »DROP AUTHORIZATION« vorstellen
kann – außer, daß (a) es im Standard so etwas wie eine Autorisierung nicht gibt,
(statt dessen gibt es »Rechtedeskriptoren«) und (b) im Gegensatz zu Objekten, die
wirklich mit Hilfe expliziter CREATE- und DROP-Anweisungen erzeugt und gelöscht werden, diese Autorisierungen (oder eher Rechtedeskriptoren) keine Namen
besitzen.
152
6.3 GRANT und REVOKE
6.3.1
GRANT
Das allgemeine Format von GRANT ist:
GRANT rechte ON objekt TO benutzer [
WITH
GRANT
OPTION
]
wobei:
rechte ist eine Kommaliste mit Rechten oder der Ausdruck ALL PRIVILEGES.
Hinweis: ALL PRIVILEGES bedeutet nicht alle Rechte im wörtlichen Sinne – es bedeutet alle Rechte an diesem Objekt, für das die aktuelle authID (das heißt, der Benutzer, der GRANT verwendet) die Berechtigung zur Rechtevergabe hat. Das Recht
INSERT(x,y), wobei x und y Kommalisten mit Spaltennamen sind) ist als Abkürzung
für die Rechteliste INSERT(x), INSERT(y) definiert (und entsprechend für UPDATE
und REFERENCES).
objekt ist eines der folgenden:
DOMAIN domäne
[ TABLE ] tabelle
CHARACTER SET zeichenmenge
COLLATION zeichenordnung
TRANSLATION zeichenübersetzung
Man beachte, daß das Schlüsselwort TABLE im Fall TABLE optional ist, und weiterhin, daß in diesem Kontext (nicht wie in manchen anderen Fällen in SQL) tabelle jede benannte Tabelle meint – das heißt, Sichten sind genauso eingeschlossen wie
Basistabellen. Spezifiziert objekt irgend etwas anderes als eine Tabelle, darf rechte
(nur) USAGE angeben. Spezifiziert objekt eine Tabelle, kann rechte eine beliebige
Menge von Tabellenzugriffsrechten angeben; alle explizit erwähnten Spalten (beispielsweise Spalte x in INSERT(x) müssen zu der angegebenen Tabelle gehören.
Benutzer ist entweder eine Kommaliste mit authIDs oder das spezielle Schlüsselwort
PUBLIC. Mit PUBLIC sind, locker gesagt, alle dem System bekannten authIDs
(einschließlich derjenigen, die irgendwann nach der Ausführung der GRANTOperation definiert worden sind) gemeint. Genauer, »Rechte an PUBLIC zu gewähren« bedeutet, daß zu jedem gegebenen Zeitpunkt jede dem System bekannte authID
alle Rechte hat, die PUBLIC gewährt und (noch) nicht entzogen worden sind.
Die für das angegebene Objekt spezifizierten Rechte werden jeder der angegebenen
authIDs gewährt. Der Benutzer (das heißt, die aktuelle authID), der die GRANTOperation aufruft, muß alle der angegebenen Rechte haben und für jedes von ihnen
die Berechtigung zur Rechtvergabe besitzen; kein Benutzer kann ein Recht gewähren, das dieser nicht mit der GRANT-Option innehat.
153
6 Sicherheitsregeln
Hinweis: Etwas genauer sollte ich sagen, daß nicht Rechte gewährt werden, sondern
eher, daß Rechtedeskriptoren erzeugt werden. Ein solcher Deskriptor zeigt an, daß eine
bestimmte gewährende authID (grantor) einer bestimmten das Recht erhaltenden authID
(garantee) die Berechtigung zur Durchführung einer bestimmten Operation auf einem
bestimmten Objekt gewährt. Man muß sich diesen Unterschied zwischen einem Recht
und einem Rechtedeskriptor besonders dann klarmachen, wenn man überlegt, was passiert, wenn beispielsweise die Benutzer U1 und U2 beide einem anderen Benutzer U3
dasselbe Recht P an einem gewissen Objekt O entziehen (die beiden GRANTAnweisungen erzeugen zwei Deskriptoren und die REVOKE-Anweisung löscht einen
davon; somit hat U3 immer noch das Recht P an O). Meistens ist dieses Maß an Präzision allerdings nicht notwendig.
Hier einige Beispiele für GRANT (GOODSUPPS ist hier eine Sicht):
GRANT
GRANT
GRANT
GRANT
GRANT
INSERT,
SELECT
UPDATE
DELETE
SELECT
UPDATE, DELETE ON SP TO DANIEL
ON SP TO LEA WITH GRANT OPTION
( STATUS ) ON S TO URSULA
ON SP TO DANIEL, URSULA
ON GOODSUPPS TO LEA
Ich beschließe diese Diskussion von GRANT mit der Wiederholung des Punktes, daß,
wenn ein Benutzer U die Rechte SELECT, INSERT, UPDATE oder REFERENCES an
einer Basistabelle T besitzt und eine neue Spalte C hinzugefügt wird, dann die Rechte
von Benutzer U automatisch um das relevante Recht an der neuen Spalte C erweitert
werden.
6.3.2
REVOKE
Das allgemeine Format von REVOKE ist:
REVOKE [ GRANT
{ RESTRICT |
OPTION FOR
CASCADE }
]
rechte ON
objekt
FROM
benutzer
Wobei rechte, objekt und benutzer wie bei GRANT sind und die Angaben GRANT
OPTION FOR sowie RESTRICT und CASCADE in den folgenden Abschnitten diskutiert werden. Die für das angegebene Objekt angegebenen Rechte werden jeder der
angegebenen authIDs entzogen (etwas genauer: die entsprechenden Rechtedeskriptoren
werden gelöscht – vergleiche die Diskussion von GRANT oben für eine Erläuterung der
Rechtedeskriptoren).
Hinweis: Der die REVOKE-Operation auslösende Benutzer (das heißt, die aktuelle
authID) muß derjenige Benutzer gewesen sein, der diese Rechte auch gewährt hat.
Das Löschen einer Domäne, Basistabelle, Spalte oder Sicht verursacht automatisch
REVOKE... CASCADE für alle Rechte von allen Benutzern an diesem gelöschten Objekt.
154
6.4 Die GRANT-Option
6.4
Die GRANT-Option
Hat Benutzer U1 die Berechtigung zur Vergabe eines Rechtes P an einem anderen
Benutzer U2, dann hat er auch die Berechtigung, dieses Recht P an den Benutzer U2
mit der GRANT-Option zu vergeben (durch Angabe von WITH GRANT OPTION in
der GRANT-Anweisung). Ein solches Weiterreichen der GRANT-Option von U1 an
U2 bedeutet, daß U2 nun wiederum die Berechtigung zur Vergabe von Rechten an P
hat, und somit P an einen dritten Benutzer U3 vergeben kann. Und deswegen hat
natürlich auch U2 die Berechtigung, die GRANT-Option für P auch an U3 weiterzureichen und so weiter. Ein Beispiel:
U1: GRANR
U2: GRANT
U3: GRANT
SELECT
SELECT
SELECT
ON
ON
ON
TABLE
TABLE
TABLE
S
S
S
TO
TO
TO
U2
U3
U4
WITH
WITH
WITH
GRANT
GRANT
GRANT
OPTION
OPTION
OPTION
Die analoge optionale Angabe GRANT OPTION FOR in der REVOKE-Anweisung
bedeutet, daß der Benutzer nicht versucht, die angegebenen Rechte per se zu löschen, sondern nur für diese Rechte die Berechtigung zur Rechtevergabe zu widerrufen. In diesem Fall muß der Benutzer (das heißt, die aktuelle authID), der den
REVOKE-Befehl auslöst, auch die ursprüngliche GRANT-Anweisung mit der
GRANT-Option ausgeführt haben.
Beispiel:
U3: REVOKE
GRANT
OPTION
FOR SELECT
ON TABLES
S
U4
RESTRICT
Die Optionen RESTRICT beziehungsweise CASCADE in einer REVOKE-Anweisung
werden im unmittelbar folgendem Abschnitt besprochen.
6.5
RESTRICT versus CASCADE
Beachten wir noch einmal die Folge der GRANT-Anweisungen aus dem vorherigen
Abschnitt:
U1: GRANT
U2: GRANT
U3: GRANT
SELECT
SELECT
SELECT
ON
ON
ON
TABLE
TABLE
TABLE
S
S
S
TO
TO
TO
U2
U3
U4
WITH
WITH
WITH
GRANT
GRANT
GRANT
OPTION
OPTION
OPTION
Was passiert, wenn Benutzer U1 nun versucht, SELECT ON TABLES von Benutzer
U2 zu widerrufen?
U1: REVOKE
SELECT
ON
TABLE
S
FROM
U2...
Würde dieser REVOKE-Befehl exakt das tun (und nur das), was dort steht, dann
würde U2 nicht mehr länger das angegebene Recht haben, U3 und U4 aber schon.
Allerdings wären diese von U3 und U4 gehaltenen Rechte nun aufgegeben (aban155
6 Sicherheitsregeln
doned), das heißt, daß sie ursprünglich von dem von U2 gehaltenen Recht abgeleitet
waren, es dieses aber nicht mehr länger gibt.
Die Möglichkeit aufgegebener Rechte ist die Rechtfertigung (oder zumindest ein
Teil davon) für die Option RESTRICT beziehungsweise CASCADE der REVOKEAnweisung. Grundlegende Idee ist die, daß angegebene Rechte verboten sind. Wenn
demnach CASCADE angegeben ist, gelingt REVOKE und kaskadiert herunter, um
alle Rechte zu entziehen, die sonst aufgegeben würden. Ist RESTRICT angegeben,
gelingt REVOKE nur dann, wenn die explizit in der REVOKE-Operation genannten
Rechte entzogen werden und keine anderen irgendwelche aufgegebenen Rechte
hinterlassen würden. Im Beispiel wird deswegen REVOKE bei Angabe von
RESTRICT scheitern, aber bei Angabe von CASCADE gelingen (und auch die
Rechte von U3 und U4 entziehen). Dagegen könnte Benutzer U3 lediglich mit
RESTRICT erfolgreich Benutzer U4 das Recht an SELECT ON S entziehen (vorausgesetzt natürlich, daß U4 das Recht nicht an einen weiteren Benutzer U5 weitergegeben hat etc.).
Nun können nicht nur Rechte aufgegeben werden; beispielsweise würde eine Sicht
aufgegeben werden, wenn ihr Eigentümer das Recht an SELECT für eine Tabelle
verliert, die in der Definition dieser Sicht verwendet wird. Analoge Bemerkungen
treffen auch auf Bedingungen zu. REVOKE... RSTRICT wird wiederum scheitern,
wenn es zu angegebenen Objekten kommen würde; REVOKE... CASCADE würde
gelingen und das Löschen solcher aufgegebenen Objekte veranlassen.
In ähnlicher Weise wären gewisse Objekte (Domänen, Spalten, Module, Schemata)
verloren, entzöge man das Recht an USAGE einer relevanten Zeichenmenge und bestimmte Objekte (Domänen, Spalten, Zeichenordnungen, Zeichenmengen) wären eingeklemmt, entzöge man das Recht an USAGE einer relevanten Zeichenordnung. Wie
aufgegebene Objekte sind verlorene und eingeklemmte Objekte verboten und die Bedeutung der REVOKE-Optionen RESTRICT und CASCADE wird entsprechend erweitert. REVOKE...RESTRICT wird scheitern, wenn dies zu irgend welchen verlorenen
oder eingeklemmten Objekten führen würde; REVOKE... CASCADE wird gelingen
und das Löschen solcher verlorener oder eingeklemmter Objekte verursachen.
All dies bedeutet, daß die Auswirkungen von REVOKE... CASCADE recht drastisch
sein können, insbesondere, wenn (a) die Definition solcher implizierten Löschungen
die CASCADE-Option da, wo anwendbar, umfaßt, und (b) alle solchen implizierten
Löschungen »ohne weitere Prüfung von Zugriffsregeln« (um den Standard zu zitieren) durchgeführt werden, was bedeutet, daß der die REVOKE-Operation auslösende
Benutzer Objekte löschen könnte, die ihm nicht gehören. Für die Praxis folgt daraus,
daß die Operation REVOKE... CASCADE wahrscheinlich mit einem gehörigen Maß
an Umsicht verwendet werden sollte.
156

Download Report