Dans Firebird il y a un compte spécial `SYSDBA' qui existe en dehors de toutes les restrictions de sécurité et qui a un accès complet à toutes les bases de données du serveur.

Sur les systèmes POSIX, y compris MacOSX, le nom d’utilisateur POSIX sera interprété comme le nom d’utilisateur de Firebird Embedded à moins que le nom d’utilisateur ne soit explicitement spécifié.

Sur les systèmes POSIX autres que MacOSX, l’utilisateur SYSDBA n’a pas de mot de passe par défaut. Si une installation complète est effectuée en utilisant les scripts standards, un mot de passe à usage unique sera créé et enregistré dans un fichier texte dans le même répertoire que security4.fdb, généralement /opt/firebird/. Le fichier de mot de passe est nommé SYSDBA.password.

Sur les systèmes POSIX, l’utilisateur root peut agir comme SYSDBA. Firebird Embedded traitera alors le nom d’utilisateur root comme SYSDBA et vous aurez accès à toutes les bases de données du serveur.

Sur les systèmes d’exploitation de la famille Windows NT, vous pouvez également utiliser les informations d’identification du système d’exploitation. Pour cela, le fournisseur Win_Sspi doit être présent dans la liste des plugins du fichier de configuration firebird.conf (paramètre AuthServer). De plus, ce plugin doit également être présent dans la liste des plugins côté client (paramètre AuthClient).

Les administrateurs Windows n’ont pas automatiquement les permissions SYSDBA lorsqu’ils se connectent à la base de données (à condition, bien sûr, que l’autorisation de confiance soit autorisée). Le fait que les administrateurs aient ou non des permissions automatiques SYSDBA dépend de la valeur de l’indicateur AUTO ADMIN MAPPING.

Les opérateurs GRANT et REVOKE sont utilisés pour attribuer et supprimer le rôle RDB$ADMIN dans une base de données normale, tout comme les autres rôles.

Si le mot-clé DEFAULT est présent dans l’instruction GRANT, l’utilisateur recevra automatiquement des privilèges d’administration même s’il n’a pas spécifié le rôle RDB$ADMIN lors de la connexion. Seuls les administrateurs peuvent donner des privilèges au rôle RDB$ADMIN.

GRANT, REVOKE.

Pour utiliser les permissions du rôle RDB$ADMIN, l’utilisateur doit simplement le spécifier lorsqu’il se connecte à la base de données, ou bien le rôle RDB$ADMIN lui est donné à l’aide du mot-clé DEFAULT. Il peut également le spécifier ultérieurement à l’aide de l’instruction SET ROLE.

Comme personne ne peut se connecter à la base de données des utilisateurs, les instructions GRANT et REVOKE ne peuvent pas être utilisées ici. Au lieu de cela, le rôle RDB$ADMIN est accordé et retiré par les commandes de gestion des utilisateurs SQL : CREATE USER et ALTER USER, qui spécifient les options spéciales GRANT ADMIN ROLE et REVOKE ADMIN ROLE.

Seuls les administrateurs peuvent donner des privilèges au rôle RDB$ADMIN.

[fblangref-security-grant], [fblangref-security-revoke].

On peut faire de même avec l’utilitaire gsec en spécifiant le paramètre -admin pour sauvegarder l’attribut RDB$ADMIN` du compte utilisateur :

Pour gérer les comptes utilisateurs via SQL, un utilisateur qui a des droits sur le rôle RDB$ADMIN doit se connecter à une base de données avec ce rôle. Comme personne n’a le droit de se connecter à la base de données des utilisateurs, l’utilisateur doit se connecter à une base de données normale où il a également des droits sur le rôle RDB$ADMIN. Il définit le rôle lors de la connexion à la base de données normale et peut exécuter n’importe quelle requête SQL sur celle-ci. Ce n’est pas la solution la plus élégante, mais c’est la seule façon de gérer les utilisateurs via des requêtes SQL.

A moins qu’il n’y ait une base de données normale où l’utilisateur a des droits sur le rôle RDB$ADMIN, la gestion des comptes via des requêtes SQL n’est pas disponible.

Pour gérer les utilisateurs via l’utilitaire gsec, le rôle RDB$ADMIN doit être spécifié dans le commutateur -role.

Windows uniquement.

Les administrateurs du système d’exploitation Windows n’obtiennent pas automatiquement les permissions SYSDBA lorsqu’ils se connectent à une base de données (à moins, bien sûr, qu’une autorisation de confiance soit autorisée). Le fait que les administrateurs aient des droits SYSDBA automatiques dépend de la valeur de l’indicateur AUTO ADMIN MAPPING. C’est un indicateur dans chacune des bases de données qui est désactivé par défaut. Si l’indicateur AUTO ADMIN MAPPING est activé, il est effectif lorsqu’un administrateur Windows :

Après une connexion “auto admin” réussie, le rôle actuel sera RDB$ADMIN

L’activation et la désactivation de l’indicateur AUTO ADMIN MAPPING dans une base de données conventionnelle s’effectue comme suit

Ces opérateurs peuvent être exécutés par des utilisateurs disposant de droits suffisants, à savoir

Dans les bases de données normales, l’état de AUTO ADMIN MAPPING n’est vérifié que pendant la connexion. Si Administrator a le rôle RDB$ADMIN parce que le mappage automatique s’est produit pendant la connexion, il conservera ce rôle pendant toute la session, même si lui ou quelqu’un d’autre désactive le mappage automatique au même moment.

De même, l’activation de AUTO ADMIN MAPPING ne changera pas le rôle actuel dans RDB$ADMIN pour les Administrateurs qui sont déjà connectés.

Vous ne pouvez pas activer ou désactiver l’indicateur AUTO ADMIN MAPPING dans la base de données utilisateur avec l’instruction ALTER ROLE RDB$ADMIN. Cependant, vous pouvez créer un mappage global du groupe prédéfini DOMAIN_ANY_RID_ADMINS au rôle RDB$ADMIN comme suit :

Alternativement, pour activer AUTO ADMIN MAPPING dans la base de données utilisateur, vous pouvez utiliser l’utilitaire de ligne de commande gsec :

Seul SYSDBA peut activer AUTO ADMIN MAPPING s’il est désactivé, mais tout administrateur peut le désactiver.

Désactiver AUTO ADMIN MAPPING désactive le mécanisme même qui lui donnait accès et donc il ne peut pas réactiver AUTO ADMIN MAPPING. Même dans une session interactive de gsec, le nouveau paramètre du drapeau prendra effet immédiatement.