Discussion :

[tibi666]

Bonjour à tous,

je vous expose mon problème, j'ai une base de données BDD_SOURCE dans laquelle se trouve un certain nombre de tables. J'ai créé une nouvelle base de données BDD_VUE, qui contient des vues V1 et V2. V1 et V2 sont issues de SELECT avec jointure entre plusieurs tables de BDD_SOURCE.

Ces requêtes utilisent la fonction CURRENT_USER() pour récupérer l'utilisateur courant et filter les données en conséquence, j'ai donc utilisé la commande :

Code :

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

CREATE SQL SECURITY INVOKER VIEW BDD_VUE.V1 AS ...

V1 et V2 ont été crées via le compte "root" de mon serveur.

J'ai donc créé un compte "U1" ayant uniquement le droit de "SELECT" sur la base BDD_VUE.* avec la commande :

Code :

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

grant SELECT on BDD_VUE.* to 'U1'@'localhost' identified by '******';

Lorsque je me connecte avec le compte "U1", je ne parviens pas à manipuler mes vues. Il m'a fallu donner le droit de "SELECT" sur BDD_SOURCES pour "U1" et débloquer alors la situation.

Je trouve ça complètement crétin ! Ce que je trouve encore plus crétin c'est que ça fonctionne sur une version 5.0.15 de MySQL et plus sur la 5.0.37 que j'utilise en ce moment. Quel est l'intérêt de créer des vues si on doit donner les droits en lecture aux données dont ses vues sont issues ...

Bref, j'en conclu donc que comme pour le [SQL SECURITY INVOKER], il doit y avoir une subtilité que j'ai pas saisie.

Si quelqu'un à une explication, je suis preneur

[qi130]

Quel est l'intérêt de créer des vues si on doit donner les droits en lecture aux données dont ses vues sont issues

Simplement parce qu'une vue n'a pas d'existence physique, les données sont récoltées à la volée lors de l'appel à la vue. Ce qui nécessite les droits évoqués.

Il existe des vues matérialisées sous Oracle, mais ce concept semble pour l'instant ignoré de MySQL...

[tibi666]

Il va falloir me donner l'intérêt de créer des vues, si pour les exploiter il faut donner des accès à la base.

Le but est de permettre de créer des ensembles de données personnalisés par utilisateur avec uniquement les données qu'il a en charge ! C'est du cloisement, de la protection de données, je sais pas, appellez ça comme vous voulez !!!
Si je dois donner des accès en "SELECT" sur les tables sources, autant ne pas faire de vues et les laisser se démerder avec les tables directement...

En plus, dans mon cas ce sont des données sensibles parce que médicales ! Un médecin X n'a pas à voir les données du médecin Y !!! Violation du secret médical et tout le tralala ...

Ca me choque d'autant plus qu'en version 5.0.15 c'est géré correctement, mais plus dans la version 5.0.37 ...

Je vais persévérer, c'est un cauchemard je vous dis ... Je vais me réveiller

[qi130]

Il va falloir me donner l'intérêt de créer des vues, si pour les exploiter il faut donner des accès à la base.

Le but est de permettre de créer des ensembles de données personnalisés par utilisateur avec uniquement les données qu'il a en charge ! C'est du cloisement, de la protection de données, je sais pas, appellez ça comme vous voulez !!!
Si je dois donner des accès en "SELECT" sur les tables sources, autant ne pas faire de vues et les laisser se démerder avec les tables directement...

En plus, dans mon cas ce sont des données sensibles parce que médicales ! Un médecin X n'a pas à voir les données du médecin Y !!! Violation du secret médical et tout le tralala ...

Ca me choque d'autant plus qu'en version 5.0.15 c'est géré correctement, mais plus dans la version 5.0.37 ...

Je vais persévérer, c'est un cauchemard je vous dis ... Je vais me réveiller

Hola, mais je ne suis pas là pour faire la promotion des vues

Maintenant, si tu préfères travailler en direct sur les tables, je n'y vois personnellement rien à redire.

Si tu penses qu'il s'agit d'un bug, tu peux aussi le signaler

[tibi666]

Je viens de poster un topic sur le forum de MySQL AB, je verrais bien si j'obtiens une réponse.

[tibi666]

bon ben j'ai trouvé

J'ai utilisé un compte intermédiaire, compte qui sera connu que de l'administrateur.

Donc voila comment j'ai procédé :

1 - Création des comptes :

'view_user'@'localhost' sera le compte qui a les droits en SELECT sur la base db_source et sur la base db_view. C'est lui qui sera le DEFINER de toutes les requêtes à l'exception de une.

'mon_user'@'localhost' est le compte de l'utilisateur qui aura les droits SELECT et SHOW VIEW sur la base db_view, plus le droit de SELECT sur la table db_source.utilisateur. C'est ce compte là qui sera utilisé pour créer la vue db_view.utilisateur qui ne contiendra qu'un seul enregistrement correspondant à son identifiant unique utilisé dans toute la base de données.

Code :

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

1
2
3
4
5
 
GRANT SELECT ON medw.* to 'view_user'@'localhost' identified by '******';
GRANT SELECT, SHOW VIEW ON db_view.* to 'view_user'@'localhost' identified by '******';
GRANT SELECT ON db_source.utilisateur to 'mon_user'@'localhost' identified by '******';
GRANT SELECT, SHOW VIEW ON db_view.* to 'mon_user'@'localhost' identified by '******';

2 - création de la première vue. C'est la seule qui nécessite un droit d'accès à une table de la base db_source, sachant que c'est la table user et qu'on peut limiter les accès uniquement à une colonne, sont identifiant unique :

Code :

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

1
2
3
4
CREATE OR REPLACE DEFINER = CURRENT_USER SQL SECURITY INVOKER VIEW db_view.utilisateur AS
SELECT id 
FROM db_source.utilisateur
WHERE username = SUBSTRING_INDEX(CURRENT_USER(), '@', 1);

On note DEFINER = CURRENT_USER et SQL SECURITY INVOKER qui signifient que ce sont les droits de 'mon_user'@'localhost' qui seront utilisés comme créateur de la vue [DEFINER] et comme exécutant de la vue [SQL SECURITY INVOKER]

En suite on crée les autres vues avec les options DEFINER = 'view_user'@'localhost' et SQL SECURITY DEFINER qui signifie qu'on force le fait que c'est le compte 'view_user'@'localhost' qui a définie la vue [DEFINER] et qu'on utilise ce même compte pour exécuter cette vue, même si c'est le compte 'mon_user'@'localhost' qui est utlisé pour exécuter les requètes. Et comme la vue db_view.utilisateur me sert dans toutes mes jointures, c'est elle qui me permet de ne remonter que les données spécifique de l'utilisateur et de maintenir ainsi la confidentialité des données qu'il n'a pas à consulter.

Ce qui est exactement ce que je veux !!!

Mission accomplished