Firebird: Grundsatzfragen zu User / Role

[fkerber]

Hi,

wahrscheinlich sind die Fragen dämlich, aber irgendwie habe ich einige Verständnisschwierigkeiten, was die ersten Schritte mit Firebird angeht.

Also ich brauche nachher eine DB auf die mehrere Instanzen meines Programms von verschiedenen Rechnern aus zugreifen können. Daher habe ich also mal die Server-Version von Firebird installiert - soweit so gut. Da gibt es dann auch den SYSDBA, dessen Passwort ich geändert habe - auch gut.
Dann habe ich 2 Benutzer angelegt - UserA ist der, der später Zugriff auf die DB bekommen soll und UserB, den ich als "Kontrolle" benutzen will.
Jetzt habe ich als UserA eine DB angelegt und dann dort auch eine Tabelle.

Die erste Frage, die sich mir stellt:
Wieso darf sich UserB zu dieser DB verbinden bzw. wie kann ich das verhindern? Er kann zwar an der Tabelle nix verändern, aber zumindest die Tabellenstruktur sehen etc.
Es geht sogar soweit, dass UserB in dieser DB auch Tabellen erstellen kann.
Ist das ein Feature?
Geht es nicht, dass eine komplette DB einem Nutzer "gebe" und nur der darf darin "rumfummeln"? So kenne ich es zumindest ja von MySQL DBs...

Die andere Frage bezieht sich auf die Weitergabe der DB.
Wenn ich das ganze nun auf dem späteren DB-Server ans laufen bekommen möchte, dann muss ich ja dort zuerst mal FB installieren. Und dann?
Ich kopiere die FDB (inkl. Alias anlegen etc) und dann?
Muss ich dann auf dem neuen Server den gleichen Benutzer anlegen (mit gleichem Passwort) wie auf meinem Entwicklungsserver und dann kann auch auf dem Server auf die DB zugegriffen werden oder muss ich da irgendwie anders vorgehen?


Und schlussendlich noch:
Welche Rollen ;) spielen Roles?


LG, Frederic

[mkinzler]

Zitat:

Wieso darf sich UserB zu dieser DB verbinden bzw. wie kann ich das verhindern? Er kann zwar an der Tabelle nix verändern, aber zumindest die Tabellenstruktur sehen etc.
Es geht sogar soweit, dass UserB in dieser DB auch Tabellen erstellen kann.
Ist das ein Feature?
Geht es nicht, dass eine komplette DB einem Nutzer "gebe" und nur der darf darin "rumfummeln"? So kenne ich es zumindest ja von MySQL DBs...

Eigentlich dürfte sich der Benutzer nicht verbinden können ( wenn er keine Rechte auf die DB hat).
Was für Rechte hat er den?

Zitat:

Muss ich dann auf dem neuen Server den gleichen Benutzer anlegen (mit gleichem Passwort) wie auf meinem Entwicklungsserver und dann kann auch auf dem Server auf die DB zugegriffen werden oder muss ich da irgendwie anders vorgehen?

Bisher ( bis Firebird <=2.5) gibt eine Passwortdatenbank pro Server. Es reicht also die Benutzer dort anzulegen. Die Rechte/Rollen sind aber in der Anwendungsdatenbank verankert.

Zitat:

Welche Rollen spielen Roles?

Man kann Rechte statt auf Benutzer auch auf Rollen schlüsseln und dann die Rolle für einen Benutzer erlauben. Dieser kann dann bei Verbindung die Rolle "Spielen"

[fkerber]

Hi,

Zitat:

Zitat von mkinzler (Beitrag 1079702)

Was für Rechte hat er den?

ich denke mal, keine - aber wie kann ich das denn sehen?
Zumindest habe ich ihm keine gegeben.
Also ich hab einfach 2 User angelegt und mit dem einen die DB erstellt.
Mehr nicht....


LG, Frederic

[mkinzler]

Schau mal im Rechtemanager ( IBExpert)

[fkerber]

Hi,

meinst du den "Grant manager"?
Den gibt es leider nicht in der Free-Version.


LG, Frederic

[mkinzler]

SQL-Code:

select 
    * 
from 
    RDB$User_Privileges 
where
    RDB$USER = :user;

[fkerber]

Hi,

solange UserB keine Tabelle darin hat, steht da nix über ihn drin.
Legt er eine Tabelle an, dann stehen Einträge drin

Code:

RDB$USER   RDB$GRANTOR   RDB$PRIVILEGE   RDB$GRANT_OPTION   RDB$RELATION_NAME   RDB$FIELD_NAME   RDB$USER_TYPE   RDB$OBJECT_TYPE
USERB   USERB   S   1   TABLE_NAME      8   0
USERB   USERB   I   1   TABLE_NAME      8   0
USERB   USERB   U   1   TABLE_NAME      8   0
USERB   USERB   D   1   TABLE_NAME      8   0
USERB   USERB   R   1   TABLE_NAME      8   0

Kannst du daraus Rückschlüsse ziehen?

LG, Frederic

[IBExpert]

du kannst die Anmeldung an der DB verhindern, das geht bei fb21/25
mit einem Database Trigger. Erklärung und kleines Beispiel hier
http://ibexpert.net/ibe/index.php?n=...DBTriggerTypes

den kann man nur umgehen wenn man mit isql als owner oder als sysdba
einen speziellen parameter benutzt, deren kennwörter sollte aber sicherlich
eh kein unberechtigter user kennen.

Gruß
Holger
www.ibexpert.com

[fkerber]

Hi,

ah, perfekt!
D.h. also von Haus aus ist das wirklich gewollt?
Gibt es dafür nachvollziehbare Gründe?


Kannst du vllt. auch noch etwas zur DB-Weitergabe sagen?
Also was ich auf dem neuen Server einrichten muss, damit ich die DB dort nutzen kann.
Logisch erscheinen würde mir gleicher Benutzername und gleiches PW - ist das so?



LG, Frederic

[mkinzler]

Gleicher Benutzer reicht.

[fkerber]

Hi,

oha!
Ist das nicht sicherheitstechnisch problematisch?
Wenn ich mir dann eine FDB mitnehme, kann ich zu Hause einfach nur den Benutzer anlegen und hab dann vollen Zugriff?

Während ich das geschrieben hab, fällt mir noch was anderes ein:
Der Sysdba des anderen Servers hat eh Zugriff, oder? Also es entfällt sogar der Schritt des Anlegens eines namensgleichen Users und trotzdem hat man Zugriff auf eine eigentlich "gesicherte" DB?


LG, Frederic

[mkinzler]

Bisher ist es so. Beim alternativen Vulcan-Kern, der Stück für Stück in Firebird integriert wird ( soll mit Firebird 3 abgeschlossen sein), kann man wählen, ob die Benutzer in der zentralen Benutzerdatenbank, in der Anwendungsdatenbank oder einer getrennten Benutzerdatenbank gespeichert werden.
Aktuell kann man dem SYSDBA durch eine gleichnamige Rolle in der DB die Rechte entziehen.

[fkerber]

Hi,

das hatte ich in einem anderen Thread gelesen, stimmt.
Aber das würde dann immer noch das "Eindringen" mit namensgleichem User auf anderem Rechner erlauben, oder?

Mache ich mir zu viele Gedanken oder wie handlen andere das?


LG, Frederic

[mkinzler]

Ja das ist nur eine Hürde und verhindert es nur bei komplexen Usernamen. Zudem gibt es Anleitungen, wie man die Rolle aus der DB löschen kann.

Abhilfe wäre die Verwendung von Vulcan/FB 3 unstable oder die Hoffnung das Version 3 nun endlich mal kommt. ( der letzte Termin Sep. 2010 ist ja auch schon wieder verstrichen, wird wohl traditionell auf Sep. 2011 verschoben :stupid:)