
Envoyé par
SergioMaster
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
1 2
| SELECT DISTINCT RDB$OWNER_NAME AS DATABASE_OWNER FROM RDB$RELATIONS
WHERE (RDB$SYSTEM_FLAG = 1); |
B C
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.
Partager