Bei einigen Firebird Installationen können Sie gsec nur dann ausführen, wenn Sie als Superuser (root unter Linux) oder als Benutzer unter dem der Firebird Server Prozess läuft, angemeldet sind. Auf Windows Serverplattformen müssen Sie in der Regel Mitglied der Power User Gruppe oder höher sein, um gsec erfolgreich ausführen zu können.

Falls Sie über ausreichende Berechtigungen verfügen, jedoch ein Aufruf von gsec die folgende Fehlermeldung zur Folge hat „cannot attach to password database - unable to open database“:

Falls die Fehlermeldung mit „Cannot attach to services manager“ beginnt, dann kann es sein, dass der Server gar nicht läuft. In diesem Fall, gehen Sie zurück zu Testen Ihrer Installation und beheben Sie das Problem.

Auf **nix Systemen müssen Sie ./gsec anstatt von gsec verwenden. Das aktuelle Verzeichnis ist gewöhnlich nicht Bestandteil des Suchpfades. Somit kann ein einfaches gsec entweder fehlschlagen oder ein „falsches“ gsec gestartet werden.

Unter Unix-ähnlichen Systemen läuft Firebird per Default bereits unter dem Benutzer firebird und nicht als root. Unter Windows Serverplattformen können Sie den Firebird Dienst unter einem designierten Benutzeraccount (z.B. Firebird) laufen lassen. Das Standardvorgehen, nämlich den Dienst unter dem LocalSystem Benutzer laufen zu lassen, kann ein Sicherheitsrisiko nach sich ziehen, falls Ihr System an das Internet angeschlossen ist. Konsultieren Sie dazu README.instsvc im doc Unterverzeichnis, um mehr darüber zu erfahren.

Wie bereits diskutiert: Falls Ihr Firebird Server vom Netzwerk aus erreichbar ist, und das Systempasswort masterkey lautet, dann ändern Sie das Passwort.

SYSDBA ist ein sehr leistungsfähiger Account, mit vollen (zerstörerischen) Zugriffsberechtigungen für alle Firebird Datenbanken. Das Passwort sollte nur für bestimmte Datenbankadministratoren bekannt gemacht werden. Darum sollten Sie diesen Benutzeraccount nicht zum Erzeugen und zum Befüllen von regulären Datenbanken verwenden. Erstellen Sie stattdessen einen normalen Benutzeraccount, und verteilen Sie die Benutzernamen und Passwörter je nach Bedarf an Ihre Benutzer. Das Erstellen von Benutzeraccounts kann mit gsec (wie Sie bereits gesehen haben) oder einem beliebigen Dritthersteller Administrationstool erfolgen.

Jeder, der Leseberechtigungen auf Dateisystemebene für die Datenbank besitzt, kann diese kopieren, auf einem anderen System installieren und alle Daten extrahieren, möglicherweise auch sensitive Inhalte. Jeder, der Schreibberechtigungen auf Dateisystemebene besitzt, kann die Datenbankdatei beschädigen oder sogar vollständig zerstören.

Die goldene Regel dafür ist: Nur der Firebird Serverprozess muss Zugriff auf die Datenbankdatei haben. Benutzer benötigen keine, und sollten auch keine Zugriffsberechtigungen auf diese Dateien haben, nicht einmal Leseberechtigungen. Die Benutzer greifen auf die Datenbank über den Server zu, und der Server stellt sicher, dass Benutzer nur den erlaubten Zugriff auf Datenbankobjekte erhalten (wenn überhaupt).

Eine Ausnahme für die oben genannte Regel ist der sogenannte lokale oder embedded Zugriffsmodus von Firebird Classic unter Linux. Dieser Modus setzt voraus, dass Benutzer die entsprechenden Rechte auf die Datenbankdatei besitzen. Sie benötigen auch lesenden Zugriff auf die Sicherheitsdatenbank security2.fdb. Falls Sie das beunruhigt, schränken Sie den Zugriff auf die Sicherheitsdatenbank auf Dateisystemebene (und auch für andere Datenbanken, wenn Sie schon dabei sind) auf den Serverprozess ein. Die Benutzer sind dann verpflichtet, denn Zugriff über die Netzwerkschicht durchzuführen. Wie auch immer, die libfbembed.* Bibliotheken sollten nicht von Ihrem System entfernt werden, weil die Firebird Kommandozeilentools die Verwendung verweigern, wenn diese Bibliotheken nicht vorhanden sind.

(Eine weitere Ausnahme ist der Windows Embedded Server, der aber nicht Bestandteil dieser Schnellanleitung ist.)

Datenbankaliase schützen den Client davor, Kenntnisse über die physischen Speicherorte der Datenbank haben zu müssen. Durch Verwendung von Aliase kann sich ein Client z.B. zu „frodo:zappa“ verbinden, ohne hierbei wissen zu müssen, dass der tatsächliche Speicherort der Datenbank frodo:/var/firebird/music/underground/mothers_of_invention.fdb ist. Aliase erlauben auch, dass Sie Datenbanken wo anders hin verschieben können, ohne hierbei den Verbindungsstring am Client ändern zu müssen.

Aliase befinden sich in der Datei aliases.conf, mit folgendem Aussehen unter Windows:

poker = E:\Games\Data\PokerBase.fdb
blackjack.fdb = C:\Firebird\Databases\cardgames\blkjk_2.fdb

Und unter Linux:

books = /home/bookworm/database/books.fdb
zappa = /var/firebird/music/underground/mothers_of_invention.fdb

Die Verwendung von .fdb (oder einer anderen beliebigen) Erweiterung im Aliasnamen ist vollkommen optional. Natürlich muss diese Erweiterung, wenn verwendet, bei der Angabe des Alias für die Verbindung zu einer Datenbank verwendet werden.

Der DatabaseAccess Parameter in firebird.conf kann auf einen Wert Restrict gesetzt werden, um den Zugriff auf explizit angeführte Verzeichnisstrukturen einzuschränken, oder sogar auf None, um den Zugriff nur über Aliase zu erlauben. Der Vorgabewert ist All, d.h. keine Einschränkungen.

Beachten Sie, dass das nicht das selbe zu den Zugriffsberechtigungen auf Dateisystemebene ist, wie wir das vorher bereits diskutiert haben: Falls DatabaseAccess einen anderen Wert als All aufweist, dann wird der Server jeglichen Zugriff auf Datenbanken außerhalb des definierten Bereichs verweigern, sogar dann, wenn der Serverprozess ausreichende Berechtigungen für die Datenbankdatei besitzt.