Discussion :

[frantzgac]

Bonjour je teste les fonctionnalités de FB 3.0 à l'aide notamment du migration guide to firebird 3 de Carlos H.Cantu
Je me pose notamment la question de savoir "qui" est propriétaire d'une base et qui peut faire un backup
Je constate notamment que l'absence de mot de passe dans une commande GBAK n'empêche nullement le backup de se faire.
Seul cependant sysdba peut faire ce backup.
De quelle manière peut on donner ce privilège à un autre utilisateur ?
Comment peut on savoir (sans essayer) qui est l'utilisateur qui a le droit de faire un backup ?

[SergioMaster]

Je me pose notamment la question de savoir "qui" est propriétaire d'une base
Comment peut-on savoir (sans essayer) qui est l'utilisateur qui a le droit de faire un backup ?

l'utilisateur qui a créé la BDD, pas forcément SYSDBA

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT DISTINCT RDB$OWNER_NAME AS DATABASE_OWNER
FROM RDB$RELATIONS
WHERE (RDB$SYSTEM_FLAG = 1);

ou en interrogeant la pseudo table

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM SEC$USERS

qui peut faire un backup
Seul cependant sysdba peut faire ce backup.

il est clairement indiqué dans la documentation de GBAK que seul SYSDBA et le propriétaire peuvent le faire section 2.1, -U[SER] <username>

Je constate notamment que l'absence de mot de passe dans une commande GBAK n'empêche nullement le backup de se faire.

Là, je suis étonné, il faudra que je tente le coup

De quelle manière peut-on donner ce privilège à un autre utilisateur ?

Peut-être (car non testé)
en donnant le ROLE RDB$ADMIN à l'utilisateur GRANT RDB$ADMIN TO <utilisateur>.
et en utilisant l'option -ro[le] dans la ligne de commande de GBAK

(Firebird 4 a introduit des privilèges supplémentaires USE_GBAK_UTILITY/USE_NBACKUP_UTILITY qui peut être utilisé pour accorder spécifiquement à un utilisateur d'effectuer uniquement des opérations gbak/nbackup)

[SergioMaster]

En tout cas j'ai fait divers tests

Je constate notamment que l'absence de mot de passe dans une commande GBAK n'empêche nullement le backup de se faire.

ce n'est pas ce que je constate

PS C:\Users\serge> cd "c:\program files\firebird\firebird_3_0"
PS C:\program files\firebird\firebird_3_0> ./gbak.exe -t employee d:\aenvoyer\employes.fbk
gbak: ERROR:no permission for read-write access to database employee
gbak:Exiting before completion due to errors
PS C:\program files\firebird\firebird_3_0> ./gbak.exe -t -USER SYSDBA employee d:\aenvoyer\employes.fbk
gbak: ERROR:no permission for read-write access to database employee
gbak:Exiting before completion due to errors

Pour ce qui est des rôles, RDB$ADMIN, cela à l'air de fonctionner

PS C:\program files\firebird\firebird_3_0> ./gbak.exe -t -USER TOTO -password "Toto" employee d:\aenvoyer\employes.fbk
gbak: ERROR:no permission for read-write access to database employee
gbak:Exiting before completion due to errors
PS C:\program files\firebird\firebird_3_0> ./gbak.exe -v -t -role 'RDB$ADMIN' -USER TOTO -password "Toto" employee d:\aenvoyer\employes.fbk
gbak:readied database employee for backup
gbak:creating file d:\aenvoyer\employes.fbk
gbak:starting transaction
.....

[frantzgac]

De mon côté j'ai aussi fait des tests que voici sous forme d'image car je ne sais pas comment récupérer les commandes où l'on voit l'absence de mot de passe et le résultat du backup

[SergioMaster]

La seule raison que je vois à ça c'est l'utilisation d'un firebird embedded et non d'un serveur ?

[frantzgac]

maintenant une restauration sans mot de passe

[frantzgac]

La seule raison que je vois à ça c'est l'utilisation d'un firebird embedded et non d'un serveur ?

Oui en effet, j'accède à une base située sur le poste contenant le serveur.
C'est le cas le plus fréquent dans l'utilisation que je fais de Firebird.

[frantzgac]

l'utilisateur qui a créé la BDD, pas forcément SYSDBA

A ce message je réponds par quelques tests reproduits ici :
Je prends note de ces 3 propositions que je nomme :

A

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT DISTINCT RDB$OWNER_NAME AS DATABASE_OWNER FROM RDB$RELATIONS 
WHERE (RDB$SYSTEM_FLAG = 1);

B

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM SEC$USERS

C

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GRANT RDB$ADMIN TO <utilisateur>

.
Je fais les tests suivants avec Firebird 3.0 et une base ODS 12.0 nommée BASE.DB qui admet comme codes d'accès :
SYSDBA STANDARD
MYUSER MYPW
mais donc le backup ne fonctionne que avec SYSDBA (même sans mot de passe)
A retourne SYSDBA
B retourne MYUSER (inattendu)
C fonctionne à condition de se connecter avec SYSDBA
A retourne toujours SYSDBA
B retourne maintenant SYSDBA et MYUSER
la sauvegarde ne fonctionne toujours pas avec MONUSER mais seulement avec SYSDBA
BASE.DB devient BASE.BAK
Je restaure la sauvegarde faite avec SYSDBA en utilisant MYUSER (et sans mot de passe)
BASE_BAK devient BASE_R.DB
A retourne toujours SYSDBA
B Retourne uniquement MYUSER
BASE_R.DB peut maintenant être sauvegardée par MYUSER mais ne peut plus l'être par SYSDBA. On ne peut y accéder qu'à partir de MYUSER

D'après l'observation que ces tests sont fait en version embedded, j'en déduis que ces règles dépendent du contexte. Or je ne fais jamais de sauvegarde ni restauration à distance. On peut donc dire que mon "contexte" est toujours "embedded".
Par conséquent il n'est pas évident de déterminer quel utilisateur peut faire la sauvegarde (puisque dans au moins un cas la commande B retourne 2 réponses) mais il semble que l'utilisateur qui restaure devient celui qui peut sauvegarder.

[SergioMaster]

Oui en effet, j'accède à une base située sur le poste contenant le serveur.
C'est le cas le plus fréquent dans l'utilisation que je fais de Firebird.

Alors là, ce n'est pas clair.
Exemple : le poste sur lequel je travaille
Il y a un Firebird server installé (en fait 2, un FB3 sur le port 3050 et un FB4 sur le port 3054) , ce n'est pas une version embedded et je ne peux accéder à ma base de données qu'en indiquant user et mdp et ce également à partir d'autres postes de travail (Clients). Le serveur firebird est lancé en tant que service.

J'ai une application dans le répertoire de laquelle est installée une copie des unités nécessaires (voir ceci) là, pas de mot de passe ou plutôt mot de passe totalement ignoré.

car je ne sais pas comment récupérer les commandes

je suis passé par windows powershell, une sélection et du copier-coller

[frantzgac]

J'utilise Firebird à titre personnel sur un poste qui fait à la fois serveur et client. J'installe en mode serveur.
Ce n'est pas cette utilisation que me fait problème.
Je distribue une application pour professionnels libéraux qui fait la même chose sur chaque poste individuel.
Certains ont un poste serveur et plusieurs (dizaines de) clients (des écoles ou des cabinets polypraticiens). Sur les postes clients je n'installe que la partie client.
J'offre aussi un service d'accès à distance (VPS-VPN) qui fait la même chose que la ligne précédente mais le serveur est sous linux (j'en ai déjà parlé sur ce forum)
Toutes ces installations sont en Firebird 2.1 et j'ai intérêt à bien comprendre FB 3.x pour migrer progressivement toutes ces installations.
Je sais déjà qu'il faudra conserver un environnement contenant FB 2.1 pour permettre les conversions des bases des anciens clients.

[frantzgac]

je suis passé par windows powershell, une sélection et du copier-coller

Ah ! merci. j'avais complètement oublié le nom de cet utilitaire que j'avais pourtant utilisé...