Firebird Documentation IndexFirebird 2.5 SprachreferenzSicherheit → Benutzerauthentifizierung
Firebird Home Firebird Home Zurück: SicherheitFirebird Documentation IndexNach oben: SicherheitWeiter: SQL-Berechtigungen

Benutzerauthentifizierung

Inhaltsverzeichnis

Besonders privilegierte Benutzer
RDB$ADMIN-Rolle
Administratoren
SQL-Anweisungen für die Benutzerverwaltung

Die Sicherheit der gesamten Datenbank hängt davon ab, einen Benutzer bei der Überprüfung seiner Autorität zu identifizieren. Diese Prozedur ist auch bekannt als Authentifizierung. Die Informationen über Benutzer, die für den Zugriff auf einen bestimmten Firebird-Server berechtigt sind, werden in einer speziellen Sicherheitsdatenbank gespeichert, benannt als security2.fdb. Jeder Datensatz in security2.fdb ist ein Benutzerkonto für einen Benutzer.

Ein Benutzername, bestehend aus bis zu 31 Zeichen, ist ein Groß- und Kleinschreibungsunabhängiger (case-insensative) Bezeichner. Ein Benutzer muss ein Kennwort haben, von denen die ersten acht Zeichen signifikant sind. Während es gültig ist, ein Kennwort länger als acht Zeichen einzugeben, werden alle nachfolgenden Zeichen werden ignoriert. Bei Kennwörtern wird zwischen Groß- und Kleinschreibung unterschieden.

Wenn der Benutzer während der Verbindung der SYSDBA ist, der Datenbankeigentümer oder ein speziell privilegierter Benutzer, bekommt der Benutzer unbegrenzten Zugriff auf die Datenbank.

Besonders privilegierte Benutzer

In Firebird ist das SYSDBA-Konto ein „Superuser“, dass über jede Sicherheitbeschränkung hinausgeht. Es hat vollständigen Zugriff auf alle Objekte in allen regulären Datenbanken auf dem Server und volle Lese- / Schreibzugriffe auf die Konten in der Sicherheitsdatenbank security2.fdb. Kein Benutzer hat Zugriff auf die Metadaten der Sicherheitsdatenbank.

Das Standard-SYSDBA-Kennwort unter Windows und MacOS ist "masterkey" — oder "masterke", um genau zu sein, wegen der 8-stelligen Längengrenze.

Extrem wichtig!

Das Standardkennwort 'masterkey' ist über das Universum bekannt. Es sollte so schnell wie möglich geändert werden sobald die Firebird Server-Installation abgeschlossen ist.

Andere Benutzer können auf mehreren Wegen erhöhte Privilegien erwerben, von denen einige von der Betriebssystemplattform abhängig sind. Diese werden in den folgenden Abschnitten besprochen zusammengefasst in Administratoren.

POSIX Hosts

Bei POSIX-Systemen, einschließlich MacOSX, wird Firebird ein POSIX-Benutzerkonto so interpretieren, als wäre es ein Firebird-Benutzerkonto in seiner eigenen Sicherheitsdatenbank, vorausgesetzt der Server sieht die Client-Maschine als vertrauenswürdigen Host an und die Systembenutzerkonten auf dem Client und dem Server sind vorhanden. Um eine „vertrauenswürdige“ Beziehung mit dem Client-Host zu erstellen, müssen die entsprechenden Einträge in einer der Dateien /etc/hosts.equiv oder /etc/gds_hosts.equiv auf Firebirds Hostserver enthalten sein.

  • Die Datei hosts.equiv enthält vertrauenswürdige Beziehungen auf Betriebssystem-Ebene, die alle Dienste umfasst (rlogin, rsh, rcp und so weiter).
  • Die Datei gds_hosts.equiv enthält vertrauenswürdige Beziehungen nur zwischen Firebird-Hosts.

Das Format ist für beide Dateien identisch und sieht so aus:

hostname [username]

Der SYSDBA Benutzer auf POSIX

Bei POSIX-Hosts, anders als MacOSX, hat der Benutzer SYSDBA kein Standardkennwort. Wenn die vollständige Installation mit den Standard-Scripts durchgeführt wird, wird ein einmaliges Kennwort erstellt und in einer Textdatei im selben Verzeichnis, üblicherweise /opt/firebird/, wie security2.fdb gespeichert. Der Name der Kennwortdatei lautet SYSDBA.password.

Anmerkung

In einer Installation, die von einem verteilungsspezifischen Installer durchgeführt wird, kann der Standort der Sicherheits-Datenbank und der Kennwort-Datei von der Standard-Datei variieren.

Der root Benutzer

Der root Benutzer kann direkt als SYSDBA auf POSIX-Host-Systemen handeln. Firebird interpretiert root als ob es SYSDBA wäre und bietet Zugriff auf alle Datenbanken auf dem Server.

Windows Hosts

Auf Windows Server-fähigen Betriebssystemen können Betriebssystemkonten verwendet werden. Vertrauenswürdige Authentifizierung muss aktiviert werden, indem der Parameter Authentication auf Trusted oder Mixed in der Konfigurationsdatei firebird.conf gesetzt wird.

Auch bei vertrauenswürdiger Authentifizierung sind die Windows-Betriebssystemadministratoren nicht automatisch mit SYSDBA-Berechtigungen berechtigt, wenn sie eine Verbindung zu einer Datenbank herstellen. Um dies zu tun, muss die intern erstellte Rolle RDB$ADMIN von SYSDBA oder dem Datenbankeigentümer geändert werden. Für Details vgl. Abschnitt AUTO ADMIN MAPPING.

Die eingebettete Version des Firebird-Servers unter Windows verwendet keine Server-Level-Authentifizierung. Da jedoch Objekte innerhalb einer Datenbank SQL-Berechtigungen unterliegen, ist ein gültiger Benutzername und, wenn Anwendbar, eine Rolle, in den Verbindungsparametern erforderlich.

Der Datenbankeigentümer

Der „Besitzer“ einer Datenbank ist entweder der Benutzer, der CURRENT_USER, welcher zum Zeitpunkt der Erstellung benutzt wurde oder der Benutzer, der als Parameter USER und PASSWORD mit der Anweisung CREATE DATABASE verwendet wurde.

Besitzer“ ist kein Benutzername. Der Benutzer, der Eigentümer einer Datenbank ist, hat volle Administratorrechte in Bezug auf diese Datenbank, einschließlich des Rechtes, sie zu löschen, um es von einer Sicherung wiederherzustellen und zu aktivieren oder die Fähigkeit AUTO ADMIN MAPPING zu deaktivieren.

Anmerkung

Vor Firebird 2.1 hatte der Besitzer keine automatischen Privilegien über alle Datenbankobjekte, die von anderen Benutzern erstellt wurden.

RDB$ADMIN-Rolle

Die intern erstellte Rolle RDB$ADMIN ist in jeder Datenbank vorhanden. Die Zuweisung der Rolle RDB$ADMIN zu einem regulären Benutzer in einer Datenbank, gewährt diesem Benutzer die Berechtigungen des SYSDBA, aber nur in der aktuellen Datenbank.

Die erhöhten Berechtigungen werden wirksam, wenn der Benutzer sich mit der RDB$ADMIN-Rolle in die Datenbank anmeldet und somit volle Kontrolle über alle Objekte in der Datenbank gibt.

Wird die RDB$ADMIN-Rolle in der Sicherheitsdatenbank gewährt, verleiht die Autorität die Erstellung, Bearbeitung und Löschung von Benutzerkonten.

In beiden Fällen kann der Benutzer mit den erhöhten Berechtigungen die RDB$ADMIN-Rolle an jeden anderen Benutzer vergeben. Mit anderen Worten wird die Angabe von WITH ADMIN OPTION unnötig, weil es in die Rolle eingebaut ist.

Gewähren der RDB$ADMIN-Rolle in der Sicherheitsdatenbank

Da niemand — nicht einmal SYSDBA — sich mit der Sicherheitsdatenbank verbinden kann, können GRANT- und REVOKE-Anweisungen für diese Aufgabe nicht genutzt werden. Stattdessen wird die Rolle RDB$ADMIN gewährt und widerrufen mit den SQL-Anweisungen für die Benutzerverwaltung:

                            CREATE USER new_user
                            PASSWORD 'password'
                            GRANT ADMIN ROLE

                            ALTER USER existing_user
                            GRANT ADMIN ROLE

                            ALTER USER existing_user
                            REVOKE ADMIN ROLE
                        

Anmerkung

GRANT ADMIN ROLE und REVOKE ADMIN ROLE sind keine Aussagen im GRANT- und REVOKE-Lexikon. Sie sind Drei-Wort-Parameter zu den Anweisungen CREATE USER und ALTER USER.

Tabelle 10.1. Parameter für die RDB$ADMIN Rollen GRANT und REVOKE

Parameter Beschreibung
new_user Verwenden Sie CREATE USER, Name für den neuen Benutzer.
existing_user Verwenden Sie ALTER USER, Name eines vorhandenen Benutzers
password Verwenden Sie CREATE USER, Kennwort für den neuen Benutzer. Das theoretische Limit sind 31 Bytes, aber nur die ersten 8 Zeichen werden berücksichtigt.


Der Gewährende muss bereits als Administrator angemeldet sein.

Siehe auch:   CREATE USER , ALTER USER

Die gleiche Aufgabe mit gsec ausführen

Eine zu verwendende Alternative ist gsec, mit dem Parameter -admin um das Attribut RDB$ADMIN auf dem Datensatz des Benutzers zu speichern:

                                gsec -add new_user -pw password -admin yes
                                gsec -mo existing_user -admin yes
                                gsec -mo existing_user -admin no
                            

Anmerkung

Abhängig vom administrativen Status des aktuellen Benutzers, können mehrere Parameter beim Aufruf von gsec benötigt werden, z.B. -user und -pass, oder -trusted.

Verwenden der RDB$ADMIN-Rolle in der Sicherheitsdatenbank

Um Benutzerkonten über SQL zu verwalten, muss der Gewährende die RDB$ADMIN-Rolle beim Verbinden bestimmen. Kein Benutzer kann eine Verbindung zur Sicherheitsdatenbank herstellen. Die Lösung ist also, dass sich der Benutzer mit einer Datenbank verbindet, für die dieser bereits RDB$ADMIN-Rechte hat und übergibt die RDB$ADMIN-Rolle mit seinen Login-Parametern. Von dort aus kann er einen beliebigen SQL-Benutzerverwaltungsbefehl ausführen.

Die SQL-Route für den Benutzer ist für jede Datenbank gesperrt, in der er nicht die RDB$ADMIN-Rolle zugewiesen bekommen hat.

Verwenden von gsec mit RDB$ADMIN-Rechten

Um die Benutzerverwaltung mit gsec durchzuführen, muss der Benutzer den zusätzlichen Schalter -role rdb$admin angeben.

Gewähren der RDB$ADMIN-Rolle in einer regulären Datenbank

In einer regulären Datenbank wird die Rolle RDB$ADMIN mit der üblichen Syntax für die Erteilung und das Widerrufen von Rollen aufgehoben und widerrufen:

                            GRANT [ROLE] RDB$ADMIN TO username

                            REVOKE [ROLE] RDB$ADMIN FROM username
                        

Um die RDB$ADMIN-Rolle zu erteilen und zu widerrufen, muss der Gewährende als Administrator eingeloggt sein.

Siehe auch:   GRANT , REVOKE

Verwenden der RDB$ADMIN-Rolle in einer regulären Datenbank

Um seine RDB$ADMIN-Privilegien auszuführen, nutzt der Gewährende einfach die Rolle in den Verbindungsattributen, sobald er eine Verbindung zur Datenbank herstellt.

AUTO ADMIN MAPPING

In Firebird 2.1 würden Windows-Administratoren automatisch SYSDBA Berechtigungen erhalten, wenn die vertrauenswürdige Authentifizierung für Serververbindungen konfiguriert wurde. In Firebird 2.5 geschieht dies nicht mehr automatisch. Die Einstellung der Schaltfläche AUTO ADMIN MAPPING legt nun fest, ob Administratoren automatisch SYSDBA-Rechte auf Datenbank-zu-Datenbank-Basis haben. Wenn eine Datenbank erstellt wird, ist sie standardmäßig deaktiviert.

Wenn AUTO ADMIN MAPPING in der Datenbank aktiviert ist, wird es wirksam, wenn ein Windows-Administrator

  1. eine vertrauenswürdige Authentifizierung verbindet und
  2. ohne eine Rolle spezifiziert.

Nach einer erfolgreichen „auto admin“ Verbindung wird die aktuelle Rolle auf RDB$ADMIN gesetzt.

Auto Admin Mapping in regulären Datenbanken

So aktivieren und deaktivieren Sie die automatische Zuordnung in einer regulären Datenbank:

                                ALTER ROLE RDB$ADMIN
                                SET AUTO ADMIN MAPPING -- aktivieren

                                ALTER ROLE RDB$ADMIN
                                DROP AUTO ADMIN MAPPING -- deaktivieren
                            

Jede Anweisung muss von einem Benutzer mit ausreichender Berechtigung ausgestellt werden, d.h:

In regulären Datenbanken wird der Status von AUTO ADMIN MAPPING nur zur Verbindungszeit überprüft. Wenn ein Administrator die Rolle RDB$ADMIN währen des Einloggens bereits hatte und die automatische Zuordnung aktiv ist, wird er diese Rolle für die Dauer der Sitzung behalten, auch wenn er oder jemand anderes die Zuordnung in der Zwischenzeit ausschaltet.

Ebenso wird das Umschalten auf AUTO ADMIN MAPPING nicht die aktuelle Rolle in RDB$ADMIN für Administratoren ändern, die bereits verbunden sind.

Auto Admin Mapping in der Sicherheitsdatenbank

Es gibt keine SQL-Anweisungen, um die automatische Zuordnung in der Sicherheitsdatenbank ein- und auszuschalten. Stattdessen muss gsec verwendet werden:

                                gsec -mapping set

                                gsec -mapping drop
                            

Mehr gsec-Schalter können erforderlich sein, je nachdem, welche Art von Log-In Sie verwendet haben, z.B -user und -pass, oder -trusted.

Nur SYSDBA kann die automatische Zuordnung einstellen, wenn sie deaktiviert ist. Jeder Administrator kann es löschen (deaktivieren).

Administratoren

Allgemein kann man festhalten, dass ein Administrator ein Benutzer ist, der über ausreichende Rechte zum Lesen, Schreiben, Erstellen, Ändern oder Löschen von Objekten in einer Datenbank verfügt, auf die der Administratorstatus des Benutzers angewendet wird. Die folgende Tabelle fasst zusammen, wie „Superuser“-Privilegien in den verschiedenen Firebird Sicherheitskontexten aktiviert sind.

Tabelle 10.2. Administrator („Superuser“) Eigenschaften

Benutzer RDB$ADMIN Role Bemerkungen
SYSDBA Auto Besteht automatisch auf Server-Ebene. Hat volle Berechtigungen für alle Objekte in allen Datenbanken. Kann Benutzer erstellen, ändern und löschen, hat aber keinen direkten Zugriff auf die Sicherheitsdatenbank
root user on POSIX Auto Genau wie SYSDBA
Superuser on POSIX Auto Genau wie SYSDBA
Windows Administrator Set as CURRENT_ROLE if login succeeds Genau wie SYSDBA wenn alle folgenden Aussagen zutreffen:
In der firebird.conf Datei Authentifizierung = mixed / trusted und Firebird neu gestartet wird, bevor fortgefahren wird.
AUTO ADMIN MAPPING Aktiviert in allen Datenbanken, in denen der Benutzer Superuser-Berechtigungen benötigt
Login Enthält keine Rolle
Datenbankbesitzer Auto Wie SYSDBA, aber nur in der Datenbank, von der er der Besitzer ist
Regularärer Benutzer Muss vorher gewährt werden; Muss bei der Anmeldung geliefert werden Wie SYSDBA, aber nur in der Datenbank bzw. Datenbanken wo die Rolle gewährt wird
POSIX OS Benutzer Muss vorher gewährt werden; Muss bei der Anmeldung geliefert werden Wie SYSDBA, aber nur in der Datenbank bzw. Datenbanken wo die Rolle gewährt wird
Windows user Muss vorher gewährt werden; Muss bei der Anmeldung geliefert werden Wie SYSDBA, aber nur in der Datenbank bzw. Datenbanken wo die Rolle gewährt wird Nicht verfügbar wenn der config-Datei-Parameter Authentifizierung =native


SQL-Anweisungen für die Benutzerverwaltung

In Firebird 2.5 und höher werden Benutzerkonten erstellt, geändert und gelöscht, indem eine Reihe von SQL-Anweisungen verwendet wird, die von einem Benutzer mit vollständigen Administratorrechten in der Sicherheitsdatenbank übermittelt werden können.

Anmerkung

Für einen Windows-Administrator reicht AUTO ADMIN MAPPING nur in einer regulären Datenbank aus, um die Verwaltung anderer Benutzer zu ermöglichen. Anweisungen zum Aktivieren in der Sicherheitsdatenbank finden Sie unter Auto Admin Mapping in der Sicherheitsdatenbank..

Nicht privilegierte Benutzer können nur die Anweisung ALTER USER verwenden und nur einige Daten in ihren eigenen Konten bearbeiten.

CREATE USER

Benutzt für: Erstellen eines Firebird-Benutzerkontos

Verfügbar in: DSQL

Syntax: 

                            CREATE USER username PASSWORD 'password'
                            [FIRSTNAME 'firstname']
                            [MIDDLENAME 'middlename']
                            [LASTNAME 'lastname']
                            [GRANT ADMIN ROLE];
                        

Tabelle 10.3. CREATE USER Statement Parameter

Parameter Beschreibung
username Benutzername. Die maximale Länge beträgt 31 Zeichen. Folgt den Regeln für reguläre Bezeichner in Firebird. Ist immer unabhängig von Groß- und Kleinschreibung (case-insensative)
password Benutzer-Kennwort. Seine theoretische Grenze sind 31 Bytes, aber nur die ersten 8 Zeichen werden berücksichtigt. Groß- / Kleinschreibung beachten
firstname Optional: Vorname des Benutzers. Maximale Länge 31 Zeichen
middlename Optional: Name des Benutzers. Maximale Länge 31 Zeichen
lastname Optional: Nachname des Benutzers. Maximale Länge 31 Zeichen


Verwenden Sie eine CREATE USER-Anweisung, um ein neues Firebird-Benutzerkonto zu erstellen. Der Benutzer darf nicht bereits in der Firebird-Sicherheitsdatenbank vorhanden sein, sonst wird eine primäre Schlüsselverletzungsfehlermeldung (primary key violation error message) zurückgegeben.

Das Argument <username muss den Regeln für reguläre Bezeichner in Firebird entsprechen: siehe Identifikatoren im Kapitel Struktur. Benutzernamen sind immer unempfindlich gegen Groß- und Kleinschreibung (case-insensitive). Die Angabe eines Benutzernamens, der in doppelten Anführungszeichen eingeschlossen ist, wird keine Ausnahme (Exception) verursachen: Die Anführungszeichen werden ignoriert. Wenn ein Leerzeichen das einzige illegale Zeichen ist, wird der Benutzername auf das erste Leerzeichen zurückgeschnitten. Andere illegale Zeichen verursachen einen Ausnahme.

Die PASSWORD-Klausel gibt das Kennwort des Benutzers an. Ein Kennwort von mehr als acht Zeichen wird mit einer Warnung akzeptiert, aber überschüssige Zeichen werden ignoriert.

Mit den optionalen Klauseln FIRSTNAME, MIDDLENAME und LASTNAME können Sie weitere Benutzereigenschaften wie den Vornamen der Person, den Vornamen und den Nachnamen angeben. Sie sind einfach nur VARCHAR(31) Felder und können verwendet werden, um alles, was Sie bevorzugen zu speichern.

Wenn die GRANT ADMIN ROLE-Klausel angegeben ist, wird das neue Benutzerkonto mit den Berechtigungen der Rolle RDB$ADMIN in der Sicherheitsdatenbank (security2.fdb) erstellt. Es erlaubt dem neuen Benutzer, Benutzerkonten aus jeder regulären Datenbank zu verwalten, in die er sich einloggt, aber er gewährt dem Benutzer keine besonderen Privilegien für Objekte in diesen Datenbanken.

Um ein Benutzerkonto zu erstellen, muss der aktuelle Benutzer in der Sicherheitsdatenbank Administratorrechte haben. Administratorrechte nur in regulären Datenbanken sind nicht ausreichend.

Anmerkung

CREATE / ALTER / DROP USER sind DDL-Anweisungen. Denken Sie daran, Ihre Arbeit zu Commiten. In isql wird der Befehl SET AUTO ON Auto-Commit auf DDL-Anweisungen aktivieren. In Drittanbieter-Tools und anderen Benutzeranwendungen muss dies nicht der Fall sein.

Beispiele: 

  1. Erstellen eines Benutzers mit dem Benutzernamen bigshot:
                                    CREATE USER bigshot PASSWORD 'buckshot';
                                
  2. Erstellen Sie den Benutzer john mit zusätzlichen Eigenschaften (Vor- und Nachname):
                                    CREATE USER john PASSWORD 'fYe_3Ksw'
                                    FIRSTNAME 'John'
                                    LASTNAME 'Doe';
                                
  3. Erstellen des Benutzers superuser mit Benutzerverwaltungsberechtigungen:
                                    CREATE USER superuser PASSWORD 'kMn8Kjh'
                                    GRANT ADMIN ROLE;
                                

Siehe auch:   ALTER USER , DROP USER

ALTER USER

Benutzt für: Ändern eines Firebird-Benutzerkontos

Verfügbar in: DSQL

Syntax: 

                            ALTER USER username
                            {
                            [SET]
                            [PASSWORD 'password']
                            [FIRSTNAME 'firstname']
                            [MIDDLENAME 'middlename']
                            [LASTNAME 'lastname']
                            }
                            [{GRANT | REVOKE} ADMIN ROLE];
                        

Tabelle 10.4. ALTER USER Statement Parameter

Parameter Beschreibung
username Benutzername. Kann nicht geändert werden.
password Benutzer-Kennwort. Seine theoretische Grenze sind 31 Bytes, aber nur die ersten 8 Zeichen werden berücksichtigt. Groß- / Kleinschreibung beachten
firstname Optional: Vorname des Benutzers oder anderer optionaler Text. Max. Länge ist 31 Zeichen
middlename Optional: Zweiter Vorname des Benutzers oder anderer optionaler Text. Max. Länge ist 31 Zeichen
lastname Optional: Nachname des Benutzers oder anderer optionaler Text. Max. Länge ist 31 Zeichen


Verwenden Sie eine ALTER USER-Anweisung, um die Details im benannten Firebird-Benutzerkonto zu bearbeiten. Um das Konto eines anderen Benutzers zu ändern, muss der aktuelle Benutzer über Administratorrechte in der Sicherheitsdatenbank verfügen. Administratorrechte nur in regulären Datenbanken sind nicht ausreichend.

Jeder Benutzer kann sein eigenes Konto ändern. Nur ein Administrator kann GRANT / REVOKE ADMIN ROLE verwenden.

Alle Argumente sind optional, aber mindestens eines von ihnen muss vorhanden sein:

  • Der Parameter PASSWORD dient zur Angabe eines neuen Passworts für den Benutzer
  • FIRSTNAME, MIDDLENAME und LASTNAME erlauben die Aktualisierung der optionalen Benutzereigenschaften wie z.B. Vorname, Vorname und Nachname
  • Hinzufügen der Klausel GRANT ADMIN ROLE gewährt dem Benutzer die Berechtigungen der Rolle RDB$ADMIN in der Sicherheitsdatenbank( security2.fdb ) und ermöglicht ihm die Konten anderer Benutzer zu verwalten. Es gewährt dem Benutzer keine besonderen Privilegien in den regulären Datenbanken.
  • Hinzufügen der Klausel REVOKE ADMIN ROLE entfernt den Administrator des Benutzers in der Sicherheitsdatenbank, die nach Beendigung der Transaktion dem Benutzer die Möglichkeit gibt, jedes Benutzerkonto außer seinem eigenen zu verändern

Anmerkung

Denken Sie daran, Ihre Arbeit zu Commiten wenn Sie in einer Anwendung arbeiten, die Auto-Commit nicht beherscht.

Beispiele: 

  1. Ändern des Passwortes für den Benutzer bobby und gewährt ihm Benutzerverwaltungsberechtigungen:
                                    ALTER USER bobby PASSWORD '67-UiT_G8'
                                    GRANT ADMIN ROLE;
                                
  2. Bearbeiten der optionalen Eigenschaften (der Vor- und Nachname) des Benutzers dan:
                                    ALTER USER dan
                                    FIRSTNAME 'No_Jack'
                                    LASTNAME 'Kennedy';
                                
  3. Widerruf von Benutzerverwaltungsberechtigungen vom Benutzer dumbbell:
                                    ALTER USER dumbbell
                                    DROP ADMIN ROLE;
                                

Siehe auch:   CREATE USER , DROP USER

DROP USER

Benutzt für: Löschen eines Firebird-Benutzerkontos

Verfügbar in: DSQL

Syntax: 

                            DROP USER username;
                        

Tabelle 10.5. DROP USER Statement Parameter

Parameter Beschreibung
username Benutzername


Verwenden Sie die Anweisung DROP USER, um ein Firebird-Benutzerkonto zu löschen. Der aktuelle Benutzer benötigt Administratorrechte.

Anmerkung

Denken Sie daran, Ihre Arbeit zu Commiten wenn Sie in einer Anwendung arbeiten, die Auto-Commit nicht beherscht.

Beispiel:  Löschen des Benutzers bobby:

                                DROP USER bobby;
                            

Siehe auch:   CREATE USER , ALTER USER

Zurück: SicherheitFirebird Documentation IndexNach oben: SicherheitWeiter: SQL-Berechtigungen
Firebird Documentation IndexFirebird 2.5 SprachreferenzSicherheit → Benutzerauthentifizierung