ROLEAnweisungen zum Widerrufen von Berechtigungen

`GRANT`

Verwendet für

Berechtigungen erteilen und Rollen zuweisen

Verfügbar in

DSQL, ESQL

Syntax (Rechte erteilen)

GRANT <privileges>
  TO <grantee_list>
  [WITH GRANT OPTION]
  [{GRANTED BY | AS} [USER] grantor]

<privileges> ::=
    <table_privileges> | <execute_privilege>
  | <usage_privilege>  | <ddl_privileges>
  | <db_ddl_privilege>

<table_privileges> ::=
  {ALL [PRIVILEGES] | <table_privilege_list> }
    ON [TABLE] {table_name | view_name}

<table_privilege_list> ::=
  <table_privilege> [, <tableprivilege> ...]

<table_privilege> ::=
    SELECT | DELETE | INSERT
  | UPDATE [(col [, col ...])]
  | REFERENCES [(col [, col ...)]

<execute_privilege> ::= EXECUTE ON
  { PROCEDURE proc_name | FUNCTION func_name
  | PACKAGE package_name }

<usage_privilege> ::= USAGE ON
  { EXCEPTION exception_name
  | {GENERATOR | SEQUENCE} sequence_name }

<ddl_privileges> ::=
  {ALL [PRIVILEGES] | <ddl_privilege_list>} <object_type>

<ddl_privilege_list> ::=
  <ddl_privilege> [, <ddl_privilege> ...]

<ddl_privilege> ::= CREATE | ALTER ANY | DROP ANY

<object_type> ::=
    CHARACTER SET | COLLATION | DOMAIN | EXCEPTION
  | FILTER | FUNCTION | GENERATOR | PACKAGE
  | PROCEDURE | ROLE | SEQUENCE | TABLE | VIEW

<db_ddl_privileges> ::=
  {ALL [PRIVILEGES] | <db_ddl_privilege_list>} {DATABASE | SCHEMA}

<db_ddl_privilege_list> ::=
  <db_ddl_privilege> [, <db_ddl_privilege> ...]

<db_ddl_privilege> ::= CREATE | ALTER | DROP

<grantee_list> ::= <grantee> [, <grantee> ...]

<grantee> ::=
    PROCEDURE proc_name  | FUNCTION func_name
  | PACKAGE package_name | TRIGGER trig_name
  | VIEW view_name       | ROLE role_name
  | [USER] username      | GROUP Unix_group
  | SYSTEM PRIVILEGE <sys_privilege>

<sys_privilege> ::=
 !! Siehe CREATE ROLE !!

Syntax (Rollenzzuweisung)

GRANT <role_granted_list>
  TO <role_grantee_list>
  [WITH ADMIN OPTION]
  [{GRANTED BY | AS} [USER] grantor]

<role_granted_list> ::=
  <role_granted> [, <role_granted ...]

<role_granted> ::= [DEFAULT] role_name

<role_grantee_list> ::=
  <role_grantee> [, <role_grantee> ...]

<role_grantee> ::=
    user_or_role_name
  | USER username
  | ROLE role_name

Table 1. `GRANT`-Anweisungsparameter
Parameter	Beschreibung
grantor	Der Benutzer, der die Berechtigung(en) gewährt
table_name	Tabellenname
view_name	Der Name der View
col	Name der Tabellenspalte
proc_name	Name der Stored Procedure
func_name	Name der Stored Function (oder UDF)
package_name	Name des Pakets
exception_name	Der Name einer Ausnahme (Exception)
sequence_name	Der Name einer Sequenz (Generator)
object_type	Der Typ des Metadatenobjekts
trig_name	Der Name eines Triggers
role_name	Rollenname
username	Der Benutzername, dem die Berechtigungen erteilt werden oder dem die Rolle zugewiesen ist.Wenn das Schlüsselwort `USER` fehlt, kann es auch eine Rolle sein.
Unix_group	Der Name einer Benutzergruppe in einem POSIX-Betriebssystem
sys_privilege	Ein Systemprivileg
user_or_role_name	Name eines Benutzers oder einer Rolle

Die GRANT-Anweisung gewährt Benutzern, Rollen oder anderen Datenbankobjekten ein oder mehrere Privilegien für Datenbankobjekte.

Ein normaler, authentifizierter Benutzer hat keine Berechtigungen für ein Datenbankobjekt, bis sie diesem einzelnen Benutzer, einer dem Benutzer als Standardrolle zugewiesenen Rolle oder allen Benutzern, die als Benutzer PUBLIC gebündelt sind, explizit gewährt werden.Wenn ein Objekt erstellt wird, haben nur sein Ersteller (der Eigentümer) und Administratoren Berechtigungen dafür und können anderen Benutzern, Rollen oder Objekten Berechtigungen erteilen.

Für unterschiedliche Typen von Metadatenobjekten gelten unterschiedliche Berechtigungen.Die verschiedenen Arten von Berechtigungen werden später in diesem Abschnitt separat beschrieben.

Note	`SCHEMA` ist derzeit ein Synonym für `DATABASE`;dies kann sich in einer zukünftigen Version ändern, daher empfehlen wir immer `DATABASE` zu verwenden

Die `TO`-Klausel

Die TO-Klausel gibt die Benutzer, Rollen und anderen Datenbankobjekte an, denen die in privileges aufgezählten Privilegien gewährt werden sollen.Die Klausel ist obligatorisch.

Mit dem optionalen Schlüsselwort USER in der TO-Klausel können Sie genau angeben, wem oder was die Berechtigung erteilt wird.Wenn kein Schlüsselwort USER (oder ROLE) angegeben ist, sucht der Server zuerst nach einer Rolle mit diesem Namen, und wenn keine solche Rolle vorhanden ist, werden dem Benutzer mit diesem Namen die Privilegien ohne weitere Prüfung gewährt.

Tip	Es wird empfohlen, `USER` und `ROLE` immer explizit anzugeben, um Mehrdeutigkeiten zu vermeiden.Zukünftige Versionen von Firebird können 'BENUTZER' obligatorisch machen.

Important

Wenn eine GRANT-Anweisung ausgeführt wird, wird die Sicherheitsdatenbank nicht auf die Existenz des Grantee-Benutzers überprüft.Dies ist kein Fehler: SQL-Berechtigungen betreffen die Kontrolle des Datenzugriffs für authentifizierte Benutzer, sowohl native als auch vertrauenswürdige, und vertrauenswürdige Betriebssystembenutzer werden nicht in der Sicherheitsdatenbank gespeichert.
Wenn Sie einem anderen Datenbankobjekt als einem Benutzer oder einer Rolle, wie einer Prozedur, einem Auslöser oder einer Ansicht, eine Berechtigung erteilen, müssen Sie den Objekttyp angeben.
Obwohl das Schlüsselwort USER optional ist, empfiehlt es sich, es zu verwenden, um Mehrdeutigkeiten bei Rollen zu vermeiden.
Berechtigungen, die einer Systemberechtigung gewährt werden, werden angewendet, wenn der Benutzer mit einer Rolle mit dieser Systemberechtigung angemeldet ist.

docnext count = 20

Verpacken von Privilegien in einem `ROLE`-Objekt

Eine Rolle ist ein “Container”-Objekt, das verwendet werden kann, um eine Sammlung von Berechtigungen zu packen.Die Verwendung der Rolle wird dann jedem Benutzer oder jeder Rolle gewährt, die diese Berechtigungen benötigt.Eine Rolle kann auch einer Liste von Benutzern oder Rollen zugewiesen werden.

Die Rolle muss vorhanden sein, bevor ihr Berechtigungen erteilt werden können.Syntax und Regeln finden Sie unter CREATE ROLE.Die Rolle wird aufrechterhalten, indem ihr Berechtigungen erteilt und ihr bei Bedarf Berechtigungen entzogen werden.Wenn eine Rolle gelöscht wird — siehe DROP ROLE --, verlieren alle Benutzer die durch die Rolle erworbenen Berechtigungen.Alle Rechte, die einem betroffenen Benutzer zusätzlich durch eine andere grant-Anweisung gewährt wurden, bleiben erhalten.

Sofern die Rolle nicht als Standardrolle zugewiesen wurde, muss ein Benutzer, dem eine Rolle zugewiesen wurde, diese Rolle explizit angeben, entweder mit seinen Anmeldeinformationen oder durch Aktivieren mit SET ROLE, um die zugehörigen Privilegien auszuüben.Alle anderen Berechtigungen, die dem Benutzer gewährt oder über Standardrollen erhalten werden, werden durch die explizite Angabe einer Rolle nicht beeinflusst.

Einem Benutzer kann mehr als eine Rolle zugewiesen werden.Obwohl nur eine Rolle explizit angegeben werden kann, können mehrere Rollen für einen Benutzer aktiv sein, entweder als Standardrollen oder als Rollen, die der aktuellen Rolle zugewiesen wurden.

Eine Rolle kann einem Benutzer oder einer anderen Rolle zugewiesen werden.

Kumulative Rollen

Die Möglichkeit, anderen Rollen und Standardrollen Rollen zuzuweisen, führt zu sogenannten kumulativen Rollen.Für einen Benutzer können mehrere Rollen aktiv sein, und der Benutzer erhält die kumulativen Berechtigungen aller dieser Rollen.

Wenn beim Verbinden oder Verwenden von SET ROLE eine Rolle explizit angegeben wird, übernimmt der Benutzer alle dieser Rolle gewährten Berechtigungen, einschließlich der Berechtigungen, die den sekundären Rollen gewährt wurden (einschließlich der gewährten Rollen). in dieser Nebenrolle usw.).Mit anderen Worten, wenn die primäre Rolle explizit angegeben wird, werden auch die sekundären Rollen aktiviert.Mit der Funktion RDB$ROLE_IN_USE kann überprüft werden, ob eine Rolle gerade aktiv ist.

Siehe auch [fblangref40-security-grant-role-default-de] für die Auswirkungen von DEFAULT mit kumulativen Rollen und [fblangref40-security-grant-withadminoption-de] für Auswirkungen auf die Gewährung.

Standardrollen

Eine Rolle kann als default-Rolle gewährt werden, indem der Rolle DEFAULT in der GRANT-Anweisung vorangestellt wird.Das Gewähren von Rollen als Standardrolle an Benutzer vereinfacht die Verwaltung von Berechtigungen, da es möglich ist, Berechtigungen für eine Rolle zu gruppieren und diese Gruppe von Berechtigungen einem Benutzer zu erteilen, ohne dass der Benutzer die Rolle explizit angeben muss.Benutzer können mehrere Standardrollen erhalten, die ihnen alle Berechtigungen dieser Standardrollen gewähren.

Die Auswirkungen einer Standardrolle hängen davon ab, ob die Rolle einem Benutzer oder einer anderen Rolle zugewiesen wird:

Wenn einem Benutzer eine Rolle als Standardrolle zugewiesen wird, wird die Rolle automatisch aktiviert und ihre Berechtigungen werden auf den Benutzer angewendet, ohne dass die Rolle explizit angegeben werden muss.

Standardmäßig aktive Rollen werden nicht von CURRENT_ROLE zurückgegeben, aber die Funktion RDB$ROLE_IN_USE kann verwendet werden, um zu überprüfen, ob eine Rolle ist gerade aktiv.
Wenn eine Rolle einer anderen Rolle als Standardrolle zugewiesen wird, werden die Rechte dieser Rolle nur dann automatisch auf den Benutzer angewendet, wenn dem Benutzer die primäre Rolle als Standardrolle zugewiesen wird, andernfalls muss die primäre Rolle explizit angegeben werden (mit anderen Worten, es verhält sich genauso, als ob die sekundäre Rolle ohne die DEFAULT-Klausel gewährt wurde).

Für eine Reihe von gewährten Rollen müssen alle Rollen als Standardrolle zugewiesen werden, damit sie automatisch angewendet werden.Das heißt, für "`GRANT DEFAULT ROLEA TO ROLE ROLEB`, GRANT ROLEB TO ROLE ROLEC, GRANT DEFAULT ROLEC TO USER USER1 ist standardmäßig nur ROLEC für BENUTZER1 aktiv.Um die Privilegien von ROLEA und ROLEB zu übernehmen, muss ROLEC explizit angegeben werden oder ROLEB muss DEFAULT für ROLEC gewährt werden.

Der Benutzer `PUBLIC`

Firebird hat einen vordefinierten Benutzer namens PUBLIC, der alle Benutzer repräsentiert.Privilegien für Operationen an einem bestimmten Objekt, die dem Benutzer "PUBLIC" gewährt werden, können von jedem authentifizierten Benutzer ausgeübt werden.

Important

Wenn dem Benutzer PUBLIC Privilegien gewährt werden, sollten diese auch dem Benutzer PUBLIC entzogen werden.

Rollen zuweisen

Das Zuweisen einer Rolle ähnelt dem Erteilen einer Berechtigung.Eine oder mehrere Rollen können einem oder mehreren Benutzern zugewiesen werden, einschließlich des Benutzer PUBLIC, mit einer GRANT-Anweisung.

Die `WITH ADMIN OPTION`-Klausel

Die optionale WITH ADMIN OPTION-Klausel ermöglicht es den in der Benutzerliste angegebenen Benutzern, anderen Benutzern die angegebene(n) Rolle(n) zu erteilen.

Caution

Es ist möglich, diese Option PUBLIC zuzuweisen.Tun Sie das nicht!

Bei kumulativen Rollen kann ein Benutzer die WITH ADMIN OPTION einer sekundären Rolle nur dann ausüben, wenn allen Zwischenrollen auch WITH ADMIN OPTION gewährt wird.Das heißt, GRANT ROLEA TO ROLE ROLEB WITH ADMIN OPTION, GRANT ROLEB TO ROLE ROLEC, GRANT ROLEC TO USER USER1 WITH ADMIN OPTION erlaubt USER1 nur, ROLEC anderen Benutzern oder Rollen zu gewähren, während GRANT ROLEB TO ROLE ROLEC WITH ADMIN OPTION es USER1 ermöglicht ROLEA, ROLEB und ROLEC anderen Benutzern zu gewähren.

Beispiele für Rollenzuweisungen

Dem Benutzer IVAN die Rollen DIRECTOR und MANAGER zuweisen:
```
GRANT DIRECTOR, MANAGER
  TO USER IVAN;
```
Zuweisen der Rolle MANAGER an den Benutzer ALEX mit der Berechtigung, diese Rolle anderen Benutzern zuzuweisen:
```
GRANT MANAGER
  TO USER ALEX WITH ADMIN OPTION;
```
Zuweisen der Rolle DIRECTOR dem Benutzer ALEX als Standardrolle:
```
GRANT DEFAULT DIRECTOR
  TO USER ALEX;
```
Die Rolle MANAGER der Rolle DIRECTOR zuweisen:
```
GRANT MANAGER
  TO ROLE DIRECTOR;
```

Siehe auch

REVOKE

Die `WITH GRANT OPTION`-Klausel

Die optionale WITH GRANT OPTION-Klausel ermöglicht es den in der Benutzerliste angegebenen Benutzern, anderen Benutzern die in der Berechtigungsliste angegebenen Berechtigungen zu erteilen.

Caution

Diese Option kann dem Benutzer PUBLIC zugewiesen werden.Mach das nicht!

Die `GANTED BY`-Klausel

Wenn Berechtigungen in einer Datenbank gewährt werden, wird standardmäßig der aktuelle Benutzer als Erteilender aufgezeichnet.Die GRANTED BY-Klausel ermöglicht es dem aktuellen Benutzer, diese Privilegien als anderen Benutzer zu erteilen.

Wenn die REVOKE-Anweisung verwendet wird, schlägt sie fehl, wenn der aktuelle Benutzer nicht der Benutzer ist, der in der GRANTED BY-Klausel genannt wurde.

Die GRANTED BY (und AS)-Klausel kann nur vom Datenbankbesitzer und anderen Administratoren verwendet werden.Der Objektbesitzer kann GRANTED BY nur verwenden, wenn er auch über Administratorrechte verfügt.

Alternative Syntax mit `AS username`

Die nicht standardmäßige AS-Klausel wird als Synonym der GRANTED BY-Klausel unterstützt, um die Migration von anderen Datenbanksystemen zu vereinfachen.

Berechtigungen für Tabellen und Ansichten (Views)

Für Tabellen und Views ist es im Gegensatz zu anderen Metadatenobjekten möglich, mehrere Privilegien gleichzeitig zu erteilen.

Liste der Berechtigungen für Tabellen

SELECT: Erlaubt dem Benutzer oder Objekt, Daten aus der Tabelle oder Ansicht auszuwählen
INSERT: Erlaubt dem Benutzer oder Objekt, Zeilen in die Tabelle oder Ansicht einzufügen
DELETE: Ermöglicht dem Benutzer oder Objekt das Löschen von Zeilen aus der Tabelle oder Ansicht or
UPDATE: Erlaubt dem Benutzer oder Objekt, Zeilen in der Tabelle oder Ansicht zu aktualisieren, optional auf bestimmte Spalten beschränkt specific
REFERENCES: Erlaubt dem Benutzer oder Objekt, die Tabelle über einen Fremdschlüssel zu referenzieren, optional beschränkt auf die angegebenen Spalten.Wenn der primäre oder eindeutige Schlüssel, auf den der Fremdschlüssel der anderen Tabelle verweist, zusammengesetzt ist, müssen alle Spalten des Schlüssels angegeben werden.
ALL [PRIVILEGES]: Kombiniert die Privilegien SELECT, INSERT, UPDATE, DELETE und REFERENCES in einem einzigen Paket

Beispiele für `GRANT <privilege>` auf Tabellen

SELECT- und INSERT-Berechtigungen für Benutzer ALEX:

GRANT SELECT, INSERT ON TABLE SALES
  TO USER ALEX;

Das SELECT-Privileg für die Rollen MANAGER sowie ENGINEER und für den Benutzer IVAN:
```
GRANT SELECT ON TABLE CUSTOMER
  TO ROLE MANAGER, ROLE ENGINEER, USER IVAN;
```
Alle Berechtigungen für die Rolle "ADMINISTRATOR", zusammen mit der Berechtigung, anderen dieselben Berechtigungen zu erteilen:
```
GRANT ALL ON TABLE CUSTOMER
  TO ROLE ADMINISTRATOR
  WITH GRANT OPTION;
```
Die SELECT- sowie REFERENCES-Privilegien in der Spalte NAME für alle Benutzer und Objekte:
```
GRANT SELECT, REFERENCES (NAME) ON TABLE COUNTRY
TO PUBLIC;
```
Das SELECT-Privileg wird dem Benutzer IVAN vom Benutzer ALEX gewährt:
```
GRANT SELECT ON TABLE EMPLOYEE
  TO USER IVAN
  GRANTED BY ALEX;
```

Gewähren der Berechtigung UPDATE für die Spalten FIRST_NAME, LAST_NAME:

GRANT UPDATE (FIRST_NAME, LAST_NAME) ON TABLE EMPLOYEE
  TO USER IVAN;

Gewähren der INSERT-Berechtigung für die gespeicherte Prozedur ADD_EMP_PROJ:
```
GRANT INSERT ON EMPLOYEE_PROJECT
  TO PROCEDURE ADD_EMP_PROJ;
```

Die `EXECUTE`-Berechtigung

Das Privileg EXECUTE gilt für gespeicherte Prozeduren, gespeicherte Funktionen (einschließlich UDFs) und Pakete.Es ermöglicht dem Empfänger, das angegebene Objekt auszuführen und gegebenenfalls seine Ausgabe abzurufen.

Im Fall von auswählbaren gespeicherten Prozeduren verhält es sich insofern wie ein SELECT-Privileg, insofern diese Art von gespeicherter Prozedur als Reaktion auf eine SELECT-Anweisung ausgeführt wird.

Note	Bei Paketen kann das `EXECUTE'-Privileg nur für das gesamte Paket vergeben werden, nicht für einzelne Unterprogramme.

Beispiele für die Gewährung des `EXECUTE`-Privilegs

Einer Rolle das Privileg EXECUTE für eine gespeicherte Prozedur gewähren:
```
GRANT EXECUTE ON PROCEDURE ADD_EMP_PROJ
  TO ROLE MANAGER;
```
Einer Rolle das Privileg EXECUTE für eine gespeicherte Funktion gewähren:
```
GRANT EXECUTE ON FUNCTION GET_BEGIN_DATE
  TO ROLE MANAGER;
```
Gewähren des EXECUTE-Privilegs für ein Paket an den Benutzer PUBLIC:
```
GRANT EXECUTE ON PACKAGE APP_VAR
  TO USER PUBLIC;
```

Erteilen des EXECUTE-Privilegs für eine Funktion an ein Paket:

GRANT EXECUTE ON FUNCTION GET_BEGIN_DATE
  TO PACKAGE APP_VAR;

Das `USAGE`-Privileg

Um andere Metadatenobjekte als Tabellen, Ansichten, gespeicherte Prozeduren oder Funktionen, Trigger und Pakete verwenden zu können, ist es notwendig, dem Benutzer (oder Datenbankobjekten wie Trigger, Prozedur oder Funktion) das USAGE-Privileg für diese Objekte zu gewähren.

Da Firebird gespeicherte Prozeduren und Funktionen, Trigger und Paketroutinen mit den Rechten des Aufrufers ausführt, ist es notwendig, dass entweder der Benutzer oder die Routine selbst das USAGE-Privileg besitzt.

Note	In Firebird 3.0 und Firebird 4.0 ist das Privileg `USAGE` nur für Ausnahmen und Sequenzen verfügbar (in gen_id(gen_name, n) oder `nächster Wert für gen_name).Die Unterstützung des `USAGE`-Privilegs für andere Metadatenobjekte könnte in zukünftigen Versionen hinzugefügt werden.

Note

Für Sequenzen (Generatoren) gewährt das Privileg USAGE nur das Recht, die Sequenz mit der Funktion GEN_ID oder NEXT VALUE FOR zu inkrementieren.Die Anweisung SET GENERATOR ist ein Synonym für ALTER SEQUENCE … RESTART WITH … und gilt als DDL-Anweisung.Standardmäßig haben nur der Besitzer der Sequenz und Administratoren die Rechte für solche Operationen.Das Recht, den Anfangswert einer beliebigen Sequenz zu setzen, kann mit GRANT ALTER ANY SEQUENCE gewährt werden, was für allgemeine Benutzer nicht empfohlen wird.

Beispiele für die Gewährung des `USAGE`-Privilegs

Einer Rolle das Privileg USAGE für eine Sequenz gewähren:
```
GRANT USAGE ON SEQUENCE GEN_AGE
  TO ROLE MANAGER;
```
Gewähren des USAGE-Privilegs für eine Sequenz an einen Trigger:
```
GRANT USAGE ON SEQUENCE GEN_AGE
  TO TRIGGER TR_AGE_BI;
```
Gewähren des Privilegs USAGE für eine Ausnahme für ein Paket:
```
GRANT USAGE ON EXCEPTION
  TO PACKAGE PKG_BILL;
```

DDL Privileges

Standardmäßig können nur Administratoren neue Metadatenobjekte erstellen;Das Ändern oder Löschen dieser Objekte ist auf den Eigentümer des Objekts (seinen Ersteller) und Administratoren beschränkt.DDL-Berechtigungen können verwendet werden, um anderen Benutzern Berechtigungen für diese Vorgänge zu erteilen.

Verfügbare DDL-Berechtigungen

CREATE: Ermöglicht die Erstellung eines Objekts des angegebenen Typs
ALTER ANY: Ermöglicht die Änderung jedes Objekts des angegebenen Typs
DROP ANY: Ermöglicht das Löschen jedes Objekts des angegebenen Typs
ALL [PRIVILEGES]: Kombiniert die Berechtigungen CREATE, ALTER ANY und DROP ANY für den angegebenen Typ

Note	Es gibt keine separaten DDL-Berechtigungen für Trigger und Indizes.Die erforderlichen Berechtigungen werden von der Tabelle oder Sicht geerbt.Das Erstellen, Ändern oder Löschen eines Triggers oder Index erfordert das Privileg `ALTER ANY TABLE` oder `ALTER ANY VIEW`.

Beispiele für die Gewährung von DDL-Berechtigungen

Erlaube dem Benutzer JOE, Tabellen zu erstellen
```
GRANT CREATE TABLE
  TO USER Joe;
```
Erlaube dem Benutzer JOE, jede Prozedur zu ändern
```
GRANT ALTER ANY PROCEDURE
  TO USER Joe;
```

Datenbank-DDL-Berechtigungen

Die Syntax für die Vergabe von Berechtigungen zum Erstellen, Ändern oder Löschen einer Datenbank weicht von der normalen Syntax für die Vergabe von DDL-Berechtigungen für andere Objekttypen ab.

Verfügbare Datenbank-DDL-Berechtigungen

CREATE: Ermöglicht die Erstellung einer Datenbank
ALTER: Ermöglicht die Änderung der aktuellen Datenbank
DROP: Ermöglicht das Löschen der aktuellen Datenbank
ALL [PRIVILEGES]: Kombiniert die Berechtigungen ALTER und DROP.ALL beinhaltet nicht das CREATE-Privileg.

Die Berechtigungen ALTER DATABASE und DROP DATABASE gelten nur für die aktuelle Datenbank, während die DDL-Berechtigungen ALTER ANY und DROP ANY für andere Objekttypen für alle Objekte des angegebenen Typs in der aktuellen Datenbank gelten.Die Berechtigung zum Ändern oder Löschen der aktuellen Datenbank kann nur von Administratoren erteilt werden.

Das Privileg CREATE DATABASE ist ein besonderes Privileg, da es in der Sicherheitsdatenbank gespeichert wird.Eine Liste von Benutzern mit dem Privileg CREATE DATABASE ist in der virtuellen Tabelle SEC$DB_CREATORS verfügbar.Nur Administratoren in der Sicherheitsdatenbank kann die Berechtigung zum Anlegen einer neuen Datenbank erteilen.

Note	`SCHEMA` ist derzeit ein Synonym für `DATABASE`;dies kann sich in einer zukünftigen Version ändern, daher empfehlen wir immer `DATABASE` zu verwenden

Beispiele für die Gewährung von Datenbank-DDL-Berechtigungen

Gewähren von SUPERUSER die Berechtigung zum Erstellen von Datenbanken:
```
GRANT CREATE DATABASE
  TO USER Superuser;
```
Gewähren Sie JOE das Recht, ALTER DATABASE für die aktuelle Datenbank auszuführen:
```
GRANT ALTER DATABASE
  TO USER Joe;
```
Gewähren Sie FEDOR das Recht, die aktuelle Datenbank zu löschen:
```
GRANT DROP DATABASE
  TO USER Fedor;
```

GRANT

GRANT

Die TO-Klausel

docnext count = 20

Verpacken von Privilegien in einem ROLE-Objekt

Kumulative Rollen

Standardrollen

Der Benutzer PUBLIC

Rollen zuweisen

Die WITH ADMIN OPTION-Klausel