Neuer Benutzer für Firebird-Datenbank

[ralfiii]

Hallo!

Wir haben früher immer einfach als SYSDBA auf eine Firebird-Datenbank zugegriffen.

Nachdem sich das manchmal im Feld mit existierenden Anwendungen gespreizt hat (und weil man das ja nicht soll, ist ja ein Sicherheitsloch wie ich gelesen habe) haben wir das dahin gehend geändert, dass wir bei Neuinstallationen am Zielrechner in Firebird automatisch einen neuen Benutzer angelegt haben.
Unsere Anwendung hat sich dann fortan als dieser Benutzer angemeldet.

Nun hat mir ein Kunde ein Datenbankfile geschickt (wie auch immer die entstanden ist), bei dem man - wenn man sich als dieser User anmeldet und versucht eine Tabelle zu lesen kriegt man eine Fehlermeldung "no permission for read/select access to TABLE TESTTABLE".

Zum Procedere: Das Datenbankfile wird bei der Erstinstallation einfach auf den Zielrechner kopiert. (Bei upgrades der Software kann es schon vorkommen, dass die Struktur der Datenbank von einem Update-skript angepasst wird).
Erzeugt wurde das File auf meinem Entwicklungsrechner, also als sysdba. D.h. ich würde vermuten SYSDBA ist Owner von allen Tabellen.
Und: Das funktionert wunderbar. Auch mit dem "neuen" Benutzer.
Nur bei dem einen Kunden ist's schiefgefaufen und ich versteh nicht warum.

Was ist da los?
Hilfe!

[hoika]

Hallo,

da kann man nur raten.
Lass dir doch zusätzlich die security(2) schicken.
Vielleicht wurde ja beim Update-Scriopt das Grant auf den neuen User vergessen ?

Dem ganzen Ärger umgehst du, indem du die DB als dein neuer Nutzer erzeugst und veschickst,
also Backup als sysdba, Restore als UserX.

Dann ist UserX der Owner der DB und darf alles (zusätzlich zum sysdba).


Heiko

[alex517]

Zitat:

Zitat von hoika

Hallo,

Dem ganzen Ärger umgehst du, indem du die DB als dein neuer Nutzer erzeugst und veschickst,
also Backup als sysdba, Restore als UserX.

Dann ist UserX der Owner der DB und darf alles (zusätzlich zum sysdba).

Heiko

Schon mal versucht? Das geht glaube ich nicht so einfach.
alex

[hoika]

Hallo #,

nicht nur versucht, sondern auch öfters gemacht.
Einfach mal ausprobieren.

Das ist meines Wissens auch die einzige Möglichkeit,
den Owner einer bestehenden DB zu ändern,
ohne in den Systemtabellen rumzupfuschen.

Von der Kommandozeile:

gbak -b data.fdb data.fbk -user sysdba -pass masterkey
gbak -c data.fbk data2.fdb -user hoika -pass geheim ;)

Deshalb sollte man auch die Backups an einem sicheren Ort haben,
sonst käme jeder an die Daten ran,
falls sie nicht clientseitg verschlüsselt worden sind.


Heiko

[ralfiii]

Zitat:

Zitat von hoika

da kann man nur raten.
Lass dir doch zusätzlich die security(2) schicken.
Vielleicht wurde ja beim Update-Scriopt das Grant auf den neuen User vergessen ?

Die Sache ist (für mich) viel misteriöser:
In dem Update-Script ist kein grant drin.

Und im Normalfall funktioniert das trotzdem - ich kopier eine Datenbank in der NUR der SYSDBA vorkommt, leg auf dem Computer den neuen Firebird-User an ohne die Datenbank-datei dabei anzutasten und alles läuft einwandfrei. (das ist z.B. was, das ich garnicht versteh' - war mir aber bisher recht).

Soll ich also für diese Datenbank für alle Tabellen ein grant machen?
Und: Welche alle - auch die Systemtabellen?

Danke!

[hoika]

Hallo,

mysteriös ... ;)

Also. Zuerst einmal.
In der Security2.fdb stehen nur Username + verschlüsselt das Passwort (genauer der Hash).

In der eigentlichen Datenbank-Datei stehen u.a. die Rechte, und zwar immer bezogen auf den User-Namen.

Bist du sicher, dass dein Programm nicht als sydba reingeht ?

Schnapp dir mal IB-Expert.
Doppelklick auf eine Tabelle, dann rechts auf "DDL".
Dann siehst du neben dem Create Table auch die Grants.
Das erste Grant (Grant All) ist der DB-Owner.

Das Grant muss für den Owner nicht explizit gemacht werden.

Ein Grant auf System-Tabellen gibt es nicht (AFAIK).


Heiko

[ralfiii]

Zitat:

Zitat von hoika

mysteriös ... ;)

Stimmt :) - mein Gott, mein deutsch rostet auch schön ein...

Zitat:

Bist du sicher, dass dein Programm nicht als sydba reingeht ?

Ja, da bin ich 100% sicher.
Der Fehler lässt sich mit z.B. Flamerobin oder IBExpert nachvollziehen.

Zitat:

Schnapp dir mal IB-Expert.
Doppelklick auf eine Tabelle, dann rechts auf "DDL".
Dann siehst du neben dem Create Table auch die Grants.
Das erste Grant (Grant All) ist der DB-Owner.

In meinem IBExpert (Personal) lassen sich die Grants nicht anzeigen.
Flamerobin sagt zu der DDL der "kaputten" Datenbank:

SQL-Code:

CREATE TABLE SYSTEMSETTINGS(
  VALNAME Varchar(20) NOT NULL,
  VALCONTENT Blob sub_type 1,
  CONSTRAINT FK_SYSTEMSETTINGS PRIMARY KEY (VALNAME)
);
GRANT DELETE, INSERT, REFERENCES, SELECT, UPDATE
 ON SYSTEMSETTINGS TO  SYSDBA WITH GRANT OPTION;

Bei der anderen Datenbank (bei der das Select funktioniert) sieht die DDL ganz gleich aus. :wiejetzt:

[mkinzler]

Ich sehe aber keinen Grant für den neuen Benutzer

[ralfiii]

Zitat:

Zitat von mkinzler

Ich sehe aber keinen Grant für den neuen Benutzer

Ja, da ist auch keiner.
Aber das andere Datenbankfile hat auch kein grant drin und geht mit dem neuen Benutzer sehr wohl.
Das wundert mich ja so.

[mkinzler]

Das wundert mich auch. Lege doch einfach entsprechende Grants an.

[hoika]

Halo,

also IBExpert sollte das auch anzeugen.
Was mich wundert, ist dass der SYSDBA zugewiesen ist.

Das ist eigentlich nicht notwendig,
der hat ja eh die Berechtigung.

Wie sieht denn die security2.fdb aus.

Es gab mal nei Anleitung, wie man dem SYSDBA Rechte wegnehmen kann
(irgendwas mit Roles/Views anlegen in der security).


Heiko

[mkinzler]

Rolle SYSDBA anlegen, der dannn alle Rechte entziehen.

[hoika]

Hallo,

ah ja, das war es

was ich meinte, war dass da jemand an dem System schon "rumgespielt hat".


Heiko