question sur la creation d'une base [Résolu]

[vbcasimir]

Bonjour ,

J'ai installé une base firebird sur un poste 2000.

je me suis connecté en mode console pour créer une base pour l'entrainement avec l'user SYSDBA.

Par la suite j'ai crée un user X et j'ai recrée une base avec cet user X.
ce qui a fonctionné.

je ne comprends pas comment je peux créer une base avec cet user X qui normalement ne devrait pas avoir les droits ...
par exemple sous oracle seul l'user SYSDBA peut le faire.
Par contre on peut créer des tables appartenant à un certain user.

Je sais je ne suis pas sous oracle mais dans ce cas la base créer avec l'user X lui appartient totalement et il peut faire ce qu'il veut ?

Ma seconde question est si je créer un user Y sous la base crée par l'user sysdba est-il possible d'affecter une table seulement à l'user Y ?

Merci

[Barbibulle]

Envoyé par vbcasimir

Par la suite j'ai crée un user X et j'ai recrée une base avec cet user X.
ce qui a fonctionné.

je ne comprends pas comment je peux créer une base avec cet user X qui normalement ne devrait pas avoir les droits ...
par exemple sous oracle seul l'user SYSDBA peut le faire.
Par contre on peut créer des tables appartenant à un certain user.

Et bien parce que vous l'avez deviné vous n'êtes pas sous oracle
Les droits sous oracles sont différents et plus poussés je pense.

Sous fb il ya deux choses a savoir :
le SYSDBA peux accèder à tout (les bases qu'il a créé et les autres)
Un user peut en effet créer une base, il en devient le owner et aura les même droits que le SYSDBA sur la base qu'il a créé.

Envoyé par vbcasimir

Ma seconde question est si je créer un user Y sous la base crée par l'user sysdba est-il possible d'affecter une table seulement à l'user Y ?

On ne crée pas de USER pour une base, le USER est créé pour le serveur (Firebird).
Et donc si le USER Y n'est pas SYSDBA et n'est pas le OWNER de la base il ne peut pas lire les tables existantes sans que le Owner ou SYSDBA ne lui ait donné les droits (Grant).
Si vous voulez que le USER Y soit le seul à pouvoir lire une table, ce n'est pas possible car le SYSDBA (et le owner) pourront la lire de toute façon. Par contre les autres users ne pourront pas la lire.

Après rien n'empèche que sous votre base créé par SYSDBA la table soit créé par votre USER Y le rendant ainsi le OWNER de cette table.

[vbcasimir]

merci beaucoup pour la réponse ..

je pense que je vais créer un user a qui je mettrais les droits sur une table de façon a sécuriser la base .
l'user n'aura donc accès à la table et aux autres objets comme les procédures stockées etc ...

je me trompe pas on peut donner les mêmes droits d'accès sur autres objets à un user particulier tel qu'on le fait avec les tables ?

[Barbibulle]

Oui en effet on peux donner des droits à d'autres objets que les USER et on donne aux USER des droits sur d'autres objets que sur les tables.


Par exemple le USER Y peux ne pas avoir le droit de visualiser la table A. Mais on peux construire une PS ou une vue qui fait un select (partiel par exemple) sur la table A. Cette vue / PS on autorise le USER Y de la selectionner (utiliser). Il faut bien entendu donner des droits de selections sur la table A à votre vue / PS.
Celà permet de donner des droits de visualisation ou MAJ que sur certaines données (celles sélectionnées par la vue/PS).

Mais un conseil avant d'aller plus loin dans vos découvertes/expérimentations regardez bien les ROLES (règles) et utilisez plutot celles ci.
Un ROLE (ou règle c'est la même chose) est comme un user (d'un point de vue droit) c'est comme un groupe. on va lui affecter des droits.

Par exemple on va créer le ROLE COMMERCIAL et le ROLE DIRECTION.
le ROLE COMMERCIAL aura le droit de selectionner et MAJ la table client mais ne pourra pas visualiser la table SALAIRES.
Le ROLE DIRECTION pourra lui tout voir.

Vous affectez les droits aux roles comme si c'était un user.

Ensuite vous allez créer vos USER et dire que tel user a le droit d'utiliser le ROLE COMMERCIALE ou le ROLE DIRECTION (Ou les deux mais il ne peut en utiliser qu'un seul par connection).

Ainsi le gros avantage c'est dans la maintenance. S'il y a un changement de sécurité il vous suffit de modifier le ROLE plutot que toutes les personnes.
En plus si une personne évolue (passe de COMMERCIAL à DIRECTION) le changement des droits se fait très facilement en lui affetant un nouveau role plutot que de lui donner les droits un par un objet par objet.
Et enfin une nouvelle personne arrive, il suffit de lui créer son compte et lui affecter un role... Sans se soucier de devoir recréer table par table objet par objet les droits.

Voila bonne continuation

[vbcasimir]

c'est evidemment plus interessant .

Merci bien