Fehler beim CREATE DATABASE wenn man nicht SYSDBA ist

[MyRealName]

Hallo,

vielleicht weiss einer die Antwort :

Ich versuche, eine vorhandene Datenbank, wo alles dem SYSDBA gehört (wurde so erstellt und man verbindet intern mit SYSDBA von Delphi aus, bitte keine Diskussion darüber, ich habe das Projekt so übernommen und versuche es gerade von Grund her zu fixen. Vorher hat das programm nur Verbindugen zugelassen mit SYSDBA und masterkey, das habe ich schon als erstes vor einiger Zeit geändert), auf einen erstellten Nutzer zu übertragen. Das alles unter einem neu installierten Firebird 3.

Wenn ich das DB script ausführen will, kriege ich einen Fehler, dass dem User die CREATE DATABASE Option fehlt...

'no permission for CREATE acces to DATABASE F:\DB\CDA.fdb'

Ideen ?

Helge

[himitsu]

Ich wüdre dem Benutzer (der grade eingeloggt ist) einfach die nötigen Berechtigungen geben, da er sie ja scheinbar benötigt. :angle:
alter user ... grant ...

http://www.delphipraxis.net/101252-f...icherheit.html

[MyRealName]

das ist ja die Frage,.. grant was genau ? :D

[DelphiBandit]

Ich habe zwar selbst noch nicht damit gearbeitet, aber das hier wäre glaube ich ein brauchbarer Ansatz

Special form for database access

Code:

GRANT CREATE DATABASE TO [USER | ROLE] <user-name> | <role-name>;

Quelle: http://firebirdsql.org/file/document...ccess-sql.html

[jobo]

Naja, das Ganze ist ja etwas Henne/ Ei Problem oder?
Kommt jedenfalls drauf an, wie das Konzept der Anwendung ist.
- Die Anwendung braucht eine eigenständige DB?
- Die Anwendung zeckt sich irgendwo ein?
- Die Anwendung setzt voraus, dass irgendwo in irgendeiner DB ein "passender" User bereits zuvor irgendwie angelegt wurde und fragt nur dessen Login ab, um dann eine eigene DB zu kreiren.

Jedenfalls ist es dann ggf notwendig, dass initial ein Login (Admin hier z.B.Sysdba ) angegeben wird, das es erlaubt, einen neuen User für die Anwendung anzulegen. Den dann mit den entsprechenden Privileges auszustatten (und das kann nur ein anderer, existierender DBA)

Dann hat sich soweit ich weiß unter FB 3 das Userkonzept etwas weiterentwickelt. Alter Scripte / Grants sind also evtl. nicht ausreichend.

[Lemmy]

Wir sprechen hier von Firebird, nicht von Oracle oder MS SQL Server.
Eine Anwendung braucht eine Firebird? Dann einen eigenen Firebird-Dienst installieren unter eigenem Port im eigenen App-Verzeichnis.
Vorteile:
* voller Zugriff auf die Benutzerverwaltung, das SysDBA Passwort braucht nicht an Kunden gegeben werden, da ein eigener User dafür angelegt wird
* voller Zugriff auf den Dienst / die Firebirdversion: Sprich wenn es sein muss wird die alte Version deinstalliert und eine neue ausgeliefert und man braucht sich um andere Software die auf einmal nicht mehr funktioniert keine Gedanken machen.
* der Dienst kann "jederzeit" zu Wartungszwecken beendet werden

[mkinzler]

Wobei man bei FB 3 ja bei der Benutzerverwaltung flexibler ist (SECURITY3.fdb, Nutzdatenbank, getrennte Sicherheitsdatenbank).

[dataspider]

Wurde: GRANT RDB$ADMIN TO username bzw. ALTER USER existinguser GRANT ADMIN ROLE schon erwähnt?

Frank

[hoika]

Hallo,
ich hätte ja ein Backup als sysdba gemacht und das Restore dann mit dem entsprechenden Nutzer.

[MyRealName]

Ich will auf das Konzept der Sicherheitsdatenbank in jeder Datenbank selbst gehen mit FB3. Damit kann verhindert werden, dass die Nutzer sich die DB in auf einen Rechner kopieren, wo sie das SYSDBA passwort festgelegt haben und damit an alle Daten kommen.
Das Design ist wie partitionierung der Festplatte. Ich habe dann den öffentlichen Bereich (Partition), wo alle zugreifen können mit dem Standard-Nutzer (Berechtigungen werden im Programm gemacht, der Admin-Nutzer kennt das Passwort zur DB, normale Nutzer nicht, Zugriff über FLamerobin oder IbExoert gehen dannnicht für normale Nuzter).
Die 2. Partition ist mit einigen SYSDBA objekten gefüllt, die mit Lizenzierung zu tun haben, wo dann selbst der Admin nicht rankommt, nur unser Support. Jede DB hat ein eigens generiertes SYSDBA passwort, welches in der Lizenz bei uns abgelegt wird.

@hoika: Ging nicht, gehört immer noch SYSDBA danach.
@dataspider: Wurde nicht erwähnt, ich hatte die Rolle aber schon gegeben, die ist allerdings für die DB und nicht den Nutzer. Da die DB noch nicht existierte, war das nicht so erfolgreich

Helge