Ein sehr großes Problem von MaxDB ist die Dokumentation. Die Referenzdokumentation, das Handbuch, wird immer besser. Trotzdem ist der Ersteinstieg schwierig. Informationen sind verstreut. Ich hatte das Vergnügen mich gestern durch das Benutzer- und Rechtesystem von MaxDB zu hangeln, um mich für einen Kurs vorzubereiten. Es war – wieder einmal – recht anstrengend. Das Problem ist, daß für MaxDB die einführenden Ãœbersichtsartikel fehlen. Bücher wie das aus Laber, laber, laber – I machen die Situation noch fataler und beschädigen den Ruf von MaxDB. Ganz so übel wie manch einer einem glauben lassen mag ist MaxDB nun wirklich nicht.

Einführung in das Benutzer- und Rechtekonzept von MaxDB

In diesem Text geht es nicht um den [Unix-]Systembenutzer sdb aus der Gruppe sdba den MaxDB bei der Installation unter Unix anlegt. Diese Benutzer werden angelegt, um Diensten, Prozessen und Dateien einen angemessenen Benutzer zuordnen zu können. Statt von diesem beschreibt die Einführüng in das Benutzer- und Rechtekonzept von MaxDB welche Benutzer innerhalb der logischen Einheit MaxDB Datenbankinstanz existieren.

Typen von Benutzern

Grundsätzlich unterscheidet MaxDB zwischen Verwaltungs- und SQL-Nutzern und einem Zwidder aus beidem. Die Begriffe Verwaltungs- und SQL-Nutzer entstammen nicht dem offiziellen MaxDB Vokabular. Sie beschreiben jedoch sehr gut den Unterschied zwischen den “Database Manager operators” (DBM, Verwaltungs-Nutzer) und den “Database users” (SQL-Nutzer). Neben diesen Typen von Benutzern gibt es noch den Zwidder “Database System Administrator (SYSDBA user)”, der ein “Database user (DBA)” (SQL-Nutzer) ist, aber auch über die Rechte eines “Database Manager operators (DBM operator)” (Verwaltungs-Nutzer) verfügt.

Vereinfacht und etwas ungenau!

Der erste Benutzer, der in einer MaxDB Datenbankinstanz angelegt wird, ist der SYSDBA (Database System Administrator). Es gibt nur einen einzigen SYSDBA. Seit 7.6 ist sein Standardname DBADMIN und das Standardpasswort ebenfalls DBADMIN, zuvor wurde DBA/DBA verwendet.

Der SYSDBA ist ein Zwidder. Er gehört zur Gruppe der SQL-Benutzer (Database user), verfügt jedoch zusätzlich über die Rechte eines Verwaltungs-Benutzers (Database Manager operator). Ihm gehört ein Teil der Systemtabellen, die im Rahmen der Installation einer Datenbankinstanz angelegt werden (dbm Kommando: load_systab). Noch wichtiger ist jedoch, daß ihm alle nachfolgend angelegten Benutzer gehören. Das Passwort des SYSDBA/DBADMIN zu vergessen ist deshalb eine ausgesprochen schlechte Idee…

Von den Verwaltungs-Nutzern (Database Manager operators (DBM operator)), lassen sich beliebig viele anlegen. Ein Verwaltungs-Nutzer darf sich nur bei den Verwaltungs-Tools der Datenbank anmeldet. Dies sind: Database Manager GUI, dbmcli, WebDBM. Er besitzt kein Login-Recht für die SQL-Tools, d.h. er darf sich nicht im SQL Studio oder im sqlcli anmelden, um SQL-Objekte (Schemata, Tabellen, Views, …) anzulegen. Seine Aufgabe ist ausschließlich auf die Verwaltung der Datenbank zugeschnitten. Er darf also Dinge machen wie den Server starten und stoppen oder sich um Backup und Recovery kümmern.

Das Gegenstück zum Verwaltungs-Nutzer ist der SQL-Nutzer (Database users). Dieser wiederum darf keine Verwaltungsaufgaben ausführen, sonder nur mit SQL Studio und sqlcli arbeiten.

Innerhalb der Verwaltungs-Nutzer (Database Manager operators (DBM operator)) wird nicht weiter differenziert nach unterschiedlichen Typen. Die Rechteverwaltung wechselt an dieser Stelle auf Priviliges/Rechte. Die einzelnen Verwaltungs-Nutzer unterscheiden sich nur noch nach den Server-Rechten, die ihnen zugewiesen werden.

Anders bei den SQL-Nutzern. Hier zeigt sich ein Mix aus Gruppen und Privileges/Rechten. Doch dazu später mehr.

Für die erste Ãœbersicht ist es wichtig zu merken, daß zunächst zwischen Verwaltungs- und SQL-Nutzern differenziert wird und zusätzlich ein Zwidder in Form des SYSDBA existiert.

Der SYSDBA

Besonders Erstbenutzer werden viel mit dem SYSDBA (Database System Administrator) arbeiten, dem ersten Benutzer in einer Datenbankinstanz, der als einziger SQL-Benutzer auch die Rechte des Verwaltungs-Benutzer besitzt. Ab 7.6 wird der SYSDBA häufig DBADMIN (Passwort: DBADMIN) genannt, zuvor war es DBA (Passwort: DBA). Jede MaxDB Datenbankinstanz verfügt über genau einen SYSDBA.

Erstbenutzer werden ihn benutzen, weil er alle Aufgaben rund um die Datenbank erledigen kann. Ohne das Benutzer- und Rechtekonzept der Datenbank zu kennen, kann ein Einsteiger gleich loslegen. Der SYSDBA kann sowohl die Datenbank verwalten als auch SQL-Kommandos absetzen. Wenn man so möchte kann man ihn sich als “root” vorstellen.

In Produktivsystemen ist jedoch genau zu überprüfen ob es nicht zweckmäßig und sinnvoll ist die Verwendung dieses priviligierten Benutzers einzuschränken und differenzierte Benutzer zu verwenden, um bei Fehlern oder Angriffen den Schaden in Grenzen zu halten. Die Details des SYSDBA sind im MaxDB Handbuch ausführlich beschrieben und ich kann nur empfehlen die Handbuchseiten zu lesen, um für Produktivsysteme ausgefeilte Benutzer- und Rechtekonzepte zu entwerfen.

Verwaltungs-Nutzer (Database Manager operators (DBM operator))

Als Name für den ersten Verwaltungs-Nutzer wird unter MaxDB üblicherweise DBM verwendet. Wie beim DBADMIN/DBA wird der Name als Standardpasswort verwendet. Eine Ausnahme bei den Standardpassworten macht eine Datenbankinstanz, die vom MaxDB Installer (SDBSETUP) angelegt wurde. Hier wird für den DBM das Passwort übernommen, welches für den SYSDBA konfiguriert wurde.

Innerhalb der Verwaltungs-Nutzer wird nicht mehr nach Typen differenziert. Den einzelnen Nutzern können jedoch unterschiedliche Rechte zugeordnet werden.

Ein Verwaltungs-Nutzer kann vom SYSDBA oder einem anderen Verwaltungs-Nutzer (Database Manager operators (DBM operator)) angelegt werden, sofern letzterer über das Recht zur Userverwaltung verfügt. Achtung: wenn ein Verwaltungs-Nutzer über das Recht zur Userverwaltung verfügt, kann er natürlich auch seine eigenen Rechte verändern und Benutzer anlegen, die über mehr Serverrechte verfügen als er selbst.

Das Anlegen und Löschen von Verwaltungs-Nutzern kann sowohl in der Database Manager GUI als auch im dbmcli erfolgen. Der entsprechende Menupunkt in der GUI ist “Configuration -> DBM Operator…”. Die Bedienung ist selbsterklärend. Auf der Kommandozeile kann die dbmcli verwendet werden. Die DBM-Kommandos zur Benutzerverwaltung beginnen mit “user_*” und sind im Handbuch erklärt.

Das Handbuch enthält ebenfalls eine umfassende Liste zu den vorhandenen Serverrechten, die einem Verwaltungs-Benutzer zugewiesen werden können. Ein guter Einstieg ist die Seite “Server Authorizations for the DBM Server”.

Wer hat aufgepasst? Mit der Trennung von Verwaltungs- und SQL-Nutzern habe ich etwas geschummelt. Ein Verwaltungs-Nutzer kann über das Recht Accessing SQL sessions (GUI: Access to SQL session, CLI: AccessSQL) verfügen und sich über den Umweg des dbmcli mit dem Kommando sql_execute in die SQL-Welt einschleichen. Aber das ist eigentlich nicht im Sinne der Trennung von Verwaltungs-Nutzern und SQL-Nutzern, die das Benutzerkonzept vom MaxDB nahelegt. Also, aufpassen, … und bei ALTER TABLE <table_name> <sample_definition> oder CREATE USER selbst entscheiden ob diese Dinge in die Verwaltungs- oder in die SQL-Welt gehören.

SQL-Benutzer (Database users)

War die Differenzierung von Verwaltungs-Benutzern relativ einfach, wird es bei den SQL-Benutzern komplizierter. Hier gibt es ein Nebeneinander von Typen, Rechten, Gruppen und Rechtesammlungen (Rollen).

Angelegt, bearbeitet und gelöscht werden SQL-Benutzer in der Database Manager GUI oder per SQL durch bestimmte SQL-Benutzer. Die Verwendung des Menupunkt “Configuration -> Database User…” in der Database Manager GUI stellt niemanden vor besondere Probleme. Und auch die Syntax der SQL-Kommandos CREATE USER, DROP USER, ALTER USER und GRANT ist gut dokumentiert. Schwieriger ist es die Ordnungsprinzipien zu verstehen.

Typen von SQL-Benutzern (user class, user mode)

MaxDB kennt vier Typen von SQL-Benutzern:

• SYSDBA
• Database Administrator (DBA user)
• RESOURCE
• STANDARD

Der SYSDBA wurde bereits ausführlich weiter oben beschrieben. Er gehört zur Gruppe der SQL-Benutzer, nimmt jedoch eine Sonderstellung ein. Der SYSDBA besitzt die gleichen Rechte wie ein SQL-Benutzer vom Typ DBA. Anders als ein normaler Database Administrator (DBA user) hat der SYSDBA jedoch Benutzerrechte an allen SQL-Benutzern und nicht nur an denen, egal ob er den jeweiligen Benutzer selbst angelegt hat oder nicht. Verwirrenderweise hat MaxDB bis Version 7.5 den Benutzernamen DBA (Passwort DBA) für den SYSDBA verwendet, was zum Glück mit 7.6 und DBADMIN (Passwort: DBADMIN) abgestellt wurde.

SQL-Benutzer können nicht durch einen Verwaltungs-Benutzer angelegt werden. Diese Aufgabe dürfen nur der SYSDBA und ein SQL-Benutzer vom Typ Database Administrator (DBA user) übernehmen. Ein DBA darf nur ihm nachgeordnete SQL-Benutzer wie Benutzer vom Typ RESOURCE und vom Typ STANDARD anlegen. Entsprechend kann ein SQL-Benutzer vom DBA nur durch den SYSDBA verwaltet werden.

Malt man es sich zur Wiederholung auf, dann sieht es etwa so aus:

SYSDBA --- hat Besitzrechte an ---> allen SQL-Benutzern
SYSDBA --- verwaltet                  ---> DBA
DBA    --- verwaltet                  ---> RESOURCE und STANDARD

Gäbe es nicht den Wunsch verschiedene SQL-Objekte (Schemata, Tabellen, Views, …) voneinander abzugrenzen, dann bräuchte man keine aufwändigen Verwandtschaftsbeziehungen zwischen den SQL-Benutzern. Um jedoch die Zugriffsrechteverwaltung zu vereinfachen hat MaxDB einst diese Typen von SQL-Benutzern eingeführt. Mit Blick auf Schemata, die später besprochen werden, wird sich noch zeigen, daß dies alles fasch schon in Frage gestellt werden könnte.

create_user_statement> ::=
  CREATE USER <user_name> PASSWORD <password>
    [<user_mode>]
    [TIMEOUT <unsigned_integer>]
    [COSTWARNING <unsigned_integer>]
    [COSTLIMIT <unsigned_integer>]
    [[NOT] EXCLUSIVE]
    [DEFAULTCODE ASCII]
    [DEFAULTCODE UNICODE]
    [<connect_mode>]
| CREATE USER <user_name> PASSWORD <password> LIKE <source_user>
| CREATE USER <user_name> PASSWORD <password> USERGROUP <usergroup_name>

<user_mode> ::= DBA | RESOURCE | STANDARD
<connect_mode> ::= ENABLE CONNECT | DISABLE CONNECT
<source_user> ::= <user_name>

Typen (user mode, user class) von SQL-Benutzern und ihre Rechte

Ein DBA darf alle Arten von SQL-Objekten anlegen und die Rechte an diesen SQL-Objekten ganz oder teilweise an einen anderen SQL-Benutzer abtreten. Ein RESOURCE Benutzer darf ebenfalls SQL-Objekte anlegen und auch er darf die Rechte, die er an SQL-Objekten besitzt an andere Benutzer weitergeben. Anders als der DBA kann er aber keine neuen Benutzer anlegen oder bestehende Benutzer löschen.

Am wenigsten priviligiert ist ein STANDARD Benutzer. Er darf nur Views, Synonyme und temporäre Tabellen anlegen. Basistabellen oder Datenbankprozeduren können von ihm nicht angelegt werden. Sofern er über die notwendigen Rechte an den Objekten verfügt, darf er jedoch Daten verändern (INSERT, UPDATE) und löschen (DELETE).

Malt man es sich zur Wiederholung auf, dann sieht es etwa so aus:

DBA  --- verwaltet                  ---> RESOURCE und STANDARD Benutzer
DBA  --- erzeugt                     ---> alle Arten von SQL-Objekten
DBA  --- gibt Rechte weiter  ---> an andere SQL-Benutzer

RESOURCE  --- erzeugt                     ---> alle Arten von SQL-Objekten
RESOURCE  --- gibt Rechte weiter  ---> an andere SQL-Benutzer

STANDARD --- erzeugt                     ---> nur: View, Synonym, temporäre Tabelle

Welche SQL-Anweisungen ein Benutzer auf ein SQL-Objekt ausführen darf hängt davon ab, welche Rechte er an dem Objekt besitzt. Welche Rechte der Benutzer am Objekt besitzt, kann man den Systemtabellen entnehmen. Zum Beispiel hat die Systemtabelle/Katalogtabelle COLUMNS eine Spalte COLUMNPRIVILEGES welche die “Privileges of the current user for the column” anzeigt, in TABLES gibt es eine Spalte PRIVILEGES welche die “Privileges of the current user for the table” dokumentiert und es findet sich sogar in der ausführlichen Liste der Systemtabellen im Handbuch eine Tabelle TABLEPRIVILEGES. Und es gibt noch mehr zu entdecken im Handbuch.

<grant_statement> ::= GRANT <priv_spec>,... TO <grantee>,... [WITH GRANT OPTION]
| GRANT <schema_priv_spec> TO <grantee>,...
| GRANT EXECUTE ON <dbproc_name> TO <grantee>,...
| GRANT EXECUTE ON <dbfunction_name> TO <grantee>,...
| GRANT SELECT ON <sequence_name> TO <grantee>,... [WITH GRANT OPTION]

<grantee> ::= <user_name> | <usergroup_name> | <role_name> | PUBLIC

<priv_spec> ::= ALL [PRIV[ILEGES]] ON [TABLE] <table_name>,...
| <privilege>,... ON [TABLE] <table_name>,...
| <role_name>

<privilege> ::=
  ALTER
| DELETE
| INDEX
| INSERT
| REFERENCES [(<column_name>,...)]
| SELECT [(<column_name>,...)]
| SELUPD [(<column_name>,...)]
| UPDATE [(<column_name>,...)] 

<schema_priv_spec> ::= <schema_privilege> ON <schema_name>,...

<schema_privilege> ::= CREATEIN | DROPIN

Welche Rechte es gibt, läßt sich an der Syntax der SQL-Anweisung GRANT zeigen. GRANT wird benutzt, um einem SQL-Benutzer zu erlauben bestimmte Aktionen wie ALTER, DELETE, … auf einem SQL-Objekt auszuführen. Das Gegenstück zu GRANT ist REVOKE. Mit REVOKE werden einem Benutzer Recht entzogen.

Wer aufmerksam hinschaut, wird CREATE in der Liste der Rechte vermissen. CREATE fehlt, weil das Recht des Anlegens mit den Typen von SQL-Benutzern verwoben ist. Seit 7.6 unterstützt MaxDB offiziell Schemata. Schemata sind Namespaces für Datenbankobjekte. Die Syntax von GRANT zeigt ein CREATEIN Recht. Dieses Recht kann man zwar einem STANDARD Benutzer geben aber es ändert nichts daran, daß dieser in dem jeweiligen Schema nur Synonyme und Views anlegen kann aber keine Basistabellen.

Vereinfacht und etwas ungenau!

Der erste Benutzer, der in einer MaxDB Datenbankinstanz angelegt wird, ist der SYSDBA (Database System Administrator). Es gibt nur einen einzigen SYSDBA. Seit 7.6 ist sein Standardname DBADMIN und das Standardpasswort ebenfalls DBADMIN, zuvor wurde DBA/DBA verwendet.

Benutzergruppen – CREATE USERGROUP

Der Kern des MaxB Benutzer- und Rechtekonzept ist jetzt beschrieben. MaxDB bietet noch zusätzlich Benutzergruppen und Rollen an, um die Verwaltung zu verfeinern.

Benutzergruppen dienen zur Bündelung und Abgrenzung von SQL-Objekten, ähnlich wie bei einem Schema. Alle SQL-Objekte, die von einem Mitglied einer Benutzergruppe angelegt worden gehören zur Gruppe und damit automatisch zu allen Gruppenmitgliedern. Die Objekte gehörten nicht den einzelnen Benutzern, welche die Objekte angelegt haben. Die Rechte an den Objekten können nur von einem Gruppenmitglied zum anderen übertragen werden jedoch nicht an Außenstehende.

Weitere Details finden sich im Handbuch.

Rollen – CREATE ROLE

Bislang wurde die Zuordnung von SQL-Benutzern und Rechten als ein starres Kontrukt beschrieben: ein Benutzer besitzt bestimmte Rechte. Rollen brechen aus diesem Korsett aus und lassen den Benutzer eine Maske überziehen der andere Rechte zugewiesen sind als dem Benutzer selbst.

Rollen werden mit CREATE ROLE angelegt. Nur ein [SYS]DBA darf eine Rolle definieren. Ähnlich einem Benutzer lassen sich einer Rolle Rechte zuweisen mit GRANT. Eine Rolle, eine Sammlung von Rechten wiederum, kann einem Benutzer mit GRANT zur Verfügung gestellt werden.

Der Benutzer kann nun mit SET ROLE während einer Datenbanksession die ihm bislang zugewiesenen Rechte ablegen und gegen die Rechte eintauschen, die mit der spezifizierten Rolle verbunden sind.

Dank der Verwendung von Rollen kann ein und derselbe Benutzer innerhalb einer Datenbanksession seine Rechte verändern. Ohne eine neue Verbindung zur Datenbank aufbauen zu müssen, kann das Rechtekorsett gewechselt werden. Das erinnert etwas an sudo/suexec und Co., ist entsprechend mächtig und sollte mit Bedacht benutzt werden.

Dinosaurier: DOMAIN, SYSINFO, PERMLIMIT, TEMPLIMIT

Wem das noch etwas sagt: diese Dinge sind ausgestorben bzw. vom aussterben bedroht. Ich will sie auch gar nicht mehr genauer beschreiben. Das was es aktuell gibt reicht doch, oder?