Firebirdforum.de

Hallo.

Es wird in der Dokumentation mit Nachdruck darauf hingewiesen, dass nach der Installation von Firebird

1. das Passwort des SYSDBAs zu ändern ist.

2. das der SYSDBA keine Datenbank anlegen soll, dafür solle zunächst ein Benutzer angelegt werden, der (weil er vom SYSBA erzeugt wird) die Rolle ADMIN (automatisch) zugewiesen bekommt.

3. man dafür die "neue Benutzerverwaltung" verwenden solle, denn Firebirds Kommandozeilentool gsec (gsec.exe) würde bald entfernt werden.

Zu 1.
Gebe ich am Systemprompt
C:\Users\Name>gsec -user sysdba -pass masterkey -mo sysdba -pw sysbas_neues_passwort
ein, dann gibt es Grund zur Freude, denn es wurde tatsächlich ein neues Passwort (sysbas_neues_passwort) gesetzt.

Zu 2.
Durch das mit gesec erzielte Ergebnis kann nun daran gegangen werden einen Benutzer anzulegen.
Wo / wie würde denn bitte dieses Ziel mit der "neuen Benutzerverwaltung" unter Verwendung von SQL umgesetzt werden können?
Hier wird schon mal auf alter user SYSDBA set password 'Zis4_viZuna83YoYo' verwiesen. Sorry, damit hantiere ich hier schon eine ganze Weile auf die eine oder andere Weise aber in jedem Fall mit dem Firebird ISQL Tool herum, nur gelingt es mir nicht das SYDBA-Passwort damit zu ändern. Es funktioniert weder am Systemprompt noch am SQL>-Prompt.

Fazit: Mir gelingt es nicht ohne die Verwendung von gsec mittels ISQL-Tool das SYSDBA zu ändern.

Zu 3.
Es wäre sehr hilfreich hier das Vorzugehen zu beschreiben, wie mit Hilfe der neuen Benutzerverwaltung das SYSDBA-Passwort zu ändern ist. Das muss 'sitzen', denn gsec wird es ja bald nicht mehr geben ... Danke.

Viele Grüße
Gerd

Guten Morgen Gerd,

hast du dir die Referenz mal angesehen?
https://firebirdsql.org/file/documentat ... admin01-de

Dort ist beschrieben, wie Benutzer mittels SQL-Statement angelegt werden.
https://firebirdsql.org/file/documentat ... s-sql.html

Für Firebird 3.0 sind die Release Notes interessant. Schau dir mal den Abschnitt "Older Methods Deprecated" an. Vielleicht hilft das ja.

Gruß
Martin

Nun, das Folgende hat ggf. mit dem aktuelle Problem nur wenig zu tun, aber im Laufe meiner nun doch schon bald 45 Berufsjahren hat sich bei Datenbankberechtigungen folgendes herausgestellt:

Eine Datenbank wird für eine Anwendung (neu App) erstellt.
Somit benötigt diese App die volle Berechtigung über die Objekte und Daten.
In der Windowswelt bewegt man sich im Netzwerk häufig im AD (Active Directory) um sich anzumelden.
Nun eine Anmeldung dieser AD-User an der Datenbank zu ermöglichen ist laut meiner Erfahrung vollkommen unsinnig.
Denn welchen Zweck hat die Anmeldung, wenn die App sowieso sämtliche Objektberechtigungen benötigt?

In einer sog. ERP-App entstehen komplexe Daten über mehrere Tabellen in diversen Abhängigkeiten. Wenn nun durch einen blöden Zufall irgendeine Berechtigung falsch gesetzt ist, kann die App die gewünschte Aktion nicht durchführen.

Fazit: Die App hat i.d.R. einen sog. App-User, der für die komplette Datenbank zuständig ist. Für protokollarische Information, welcher User hat nun was gemacht, kann ich diese Information innerhalb meiner App aus dem aktuellen Windowsuser ja mitgeben.

Aber es geht ja noch weiter:
In einer Organisation gibt es nun mal Abteilungen (Rollen) und Mitarbeiter (User). Dass diese in irgendeiner Form Berechtigungen benötigen steht hier außer Frage.
Nur ist dies Sache der Anwendung und nicht der Datenbank!

Mehrmandantenfähigkeit:
Hier werden Rollen/Usern die zulässigen Mandanten der App zugewiesen.
Dies heißt, dass sämtliche Abfragen und Datenveränderungen grundsätzlich die Mandantenschlüssel mit führen müssen.

Sichtbarkeit von Informationen:
Dies sind Datenberechtigungen ebenso auf Rollen/User-Ebene, die die Sichtbarkeit bestimmter Dateninhalte ausschließen.
Das muss durch ein entsprechendes Konzept innerhalb der App gelöst werden.

Ausführbarkeit von Programmen/Funktionen:
Hiermit sind keine SQL-Funktionen und -Prozeduren gemeint sondern App-Funktionen: Auftragswesen, Lager, Logistik, Fertigung, Finanzen, ...
Somit gibt es eine Verwaltung der erlaubten Aufrufe, die jedes Programm-/Teilfunktion der App an entsprechender Stelle abfragt.
Dies ist nicht mit Objektberechtigungen machbar.

Schlechtes Beispiel:
Durch das neue DSGVO wurde in einer Datenbank (DB2) die Verschlüsselung und Maskierung von Daten eingeführt.
Hier können nun Feldinhalte auf Datenebene unleserlich gemacht und verändert werden. Nur leider bekommen die Programme davon nichts mehr mit.

Wenn nun z.B. ein Programm Rechnungen schreibt und die Daten der Einstandspreise (EP) für den User nicht sichtbar sein sollen, der aktuelle EP jedoch in den Rechnungsdaten für die Fibu benötigt wird, schreibt das Programm leider den maskierten Wert in die Zieltabelle, da dem ausführenden User ja die Berechtigung fehlt, diese Information weiterzugeben.

Berechtigungen auf Objektebene der Datenbank sind da nun eher Kontraproduktiv und produzieren ggf. sogar Datenmüll.

Mit unserer BI-Suite entwickeln wir nun seit 2005 mit der Firebird unser Datenmodell und haben da noch nie irgend etwas mit Benutzern auf Datenbankebene gemacht. Zumal ja das Ganze in einer Extra-DB verwaltet wird und bei Diebstahl des DB-Objektes (Datei) alle Berechtigungen sowieso hinfällig werden. Dies gilt i.Ü. für die meisten DBMS.

Da im BI-Umfeld jedoch sehr viele Daten anfallen und diese je nach User/Abteilung unterschiedliche Sichtbarkeiten haben müssen, haben wir innerhalb unserer BI-App ein entsprechendes Datenmodell für die Userverwaltung eingerichtet, in dem über Inhaltsfilter die Sichten eingeschränkt werden können. Ebenso können auch bestimmte Felder aus der Sichtbarkeit ausgeschlossen werden.
Diese Informationen werden verschlüsselt in der DB abgelegt.
Somit ist selbst bei einem Diebstahl der DB kaum etwas mit der Datenbank anzufangen (kriminelle Energie natürlich ausgeschlossen).

bfuerchau hat geschrieben: Do 10. Okt 2019, 10:37 Nun, das Folgende hat ggf. mit dem aktuelle Problem nur wenig zu tun, aber im Laufe meiner nun doch schon bald 45 Berufsjahren hat sich bei Datenbankberechtigungen folgendes herausgestellt:

Hallo bfuerchau.

Danke. Das sind für mich interessante Informationen.


Viele Grüße
Gerd

martin.koeditz hat geschrieben: Do 10. Okt 2019, 09:45 Guten Morgen Gerd,

hast du dir die Referenz mal angesehen?
https://firebirdsql.org/file/documentat ... admin01-de

Hallo Martin.

Das muss ich u. a. schon einmal gelesen haben, denn von hier habe ich sicher meine Kenntnis über das Folgende erlangt:

"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."

Ich finde aber hier keine Ansatzpunkt, wie das mittels Firebird ISQL Tool zu bewerkstelligen wäre. Wo bitte ist dort der Satz oder Abschnit, der mich auf die Spur bringt?
Mein derzeitiges Dilemma (auch nach Lektüre dieser beiden Links und anderen) ist das Folgende:
Ausgangspunkt soll mal eine taufrische Installation sein.
Um nun (wie oben gefordert) zu verhindern, dass die (hier erste) erstellte Datenbank eine Datenbank ist, die der SYSDBA erstellt hat, müsste man doch so vorgehen:

Passwort des SYSDBAs ändern.
Dilemma. Offenbar muss wohl doch erst eine Datenbank (vom SYSDBA) erstellt worden sein?
Denn sonst komme ich bspw. mit a) oder b) gar nicht erst in die Nähe eines Passwort-Wechsels:

a)
C:\Users\Name>isql ALTER USER SYSDBA PASSWORD 'masterkey' SET PASSWORD 'sysdbas_neues_password';
Ergebnis:
more than one database name: "ALTER", "USER"
usw. ...
C:\Users\Name>

b)
C:\Users\Name>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> ALTER USER SYSDBA PASSWORD 'masterkey' SET PASSWORD 'sysdbas_neues_password';
Use CONNECT or CREATE DATABASE to specify a database
SQL>

Würde a) oder b) funktionieren, dann würde ich als nächstes einen neuen USER anlegen. Unter ihm wäre dann eine (erste) neue Datenbank anzulegen.

Hättest Du noch einen Hinweis? Danke für die Bemühungen.

Viele Grüße
Gerd

Hi Gerd,

tatsächlich musst du dich erst mit einer Datenbank verbinden. Erst dann kannst du das Kennwort ändern. Bitte beachte, dass dieses Kennwort dann für diese Datenbank gilt. Seit 3.0 kann der Benutzer an die Datenbank gehängt werden und wird nicht mehr zwangsläufig über eine zentrale security.fdb gesteuert. Auf Wunsch können jedoch verschiedene Sec-DBs verwendet werden.

Gruß
Martin

martin.koeditz hat geschrieben: Do 10. Okt 2019, 12:44 ... tatsächlich musst du dich erst mit einer Datenbank verbinden. Erst dann kannst du das Kennwort ändern.

Code: Alles auswählen

ALTER USER SYSDBA PASSWORD 'neues kennwort';

Hallo Martin.

Alles klar.

Zusammenfassung:
Nach erfolgter Firebird-Installation unter Windows das SYSDBA-Passwort ändern

SYSDBA PASSWORD 'masterkey' erstellt (hoffentlich) erste Datenbank.
Mittels ALTER USER SYSDBA PASSWORD 'neues kennwort'; wird ein neues Passwort für SYSDBA erstellt.
SYSDBA PASSWORD 'neues_kennwort' erstellt einen neuen USER für die Datenbank (oder könnte sie auch löschen).

Das war es, was ich brauchte bzw. was mir gesagt werden musste.

Für mich wäre dieses Thema dann erledigt.

DANKE @Martin; @bfuerchau


Viele Grüße
Gerd


Aktualisierung: 10.10.2019; 14:20 Uhr:

Noch eine Zusatzinformation, für die, die das mit dem Firebird ISQL Tool nachvollziehen.


Die SYSDBA-Rechte reichen offenbar für die SECURITY4.FDB nicht aus:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Name>chcp 65001
Aktive Codepage: 65001.

C:\Users\Name>isql -z
ISQL Version: WI-T4.0.0.1436 Firebird 4.0 Beta 1
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'c:\users\name\documents\firebird\meine_datenbank.fdb' user 'sysdba' password 'masterkey';
Server version:
WI-T4.0.0.1436 Firebird 4.0 Beta 1
Database: 'c:\users\name\documents\firebird\meine_datenbank.fdb', User: SYSDBA
SQL> ALTER USER SYSDBA PASSWORD 'neues_passwort';
Statement failed, SQLSTATE = 28000
no permission for read-write access to database C:\PROGRAM FILES\FIREBIRD\FIREBIRD_4_0\SECURITY4.FDB
SQL>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Lösung:
Das Firebird ISQL-Tool muss hierfür mit "Als Administrator ausführen" aufgerufen/ ausgeführt werden:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>isql -z
ISQL Version: WI-T4.0.0.1436 Firebird 4.0 Beta 1
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect 'c:\users\name\documents\firebird\meine_datenbank.fdb' user 'sysdba' password 'masterkey';
Database: 'c:\users\name\documents\firebird\meine_datenbank.fdb', User: SYSDBA
SQL> ALTER USER SYSDBA PASSWORD 'neues_passwort';
SQL>


Aktualisierung: 10.10.2019; 16:25 Uhr:

Noch eine Zusatzinformation, für die, die das mit dem Firebird ISQL Tool nachvollziehen.

Parametern müssen den Regeln für reguläre Bezeichner (u.a. die Umlaut-Problematik) in Firebird entsprechen.
CREATE USER / ALTER USER: USERNAME mueller (und nicht müller, usw.)