Forums Webou.net - Hébergement gratuit et sans publicités avec PHP/MySQL Webou Webou Pro
Recherche avancée  
*
Bienvenue, Invité. Veuillez vous connecter ou vous inscrire.
Avez-vous perdu votre courriel d'activation?
18 Septembre 2019, 11:21:23


Connexion avec identifiant, mot de passe et durée de la session


Pages: [1]   Bas de page
  Imprimer  
Auteur Fil de discussion: Utilisateurs MySQL et procédures stockées  (Lu 7851 fois)
0 Membres et 1 Invité sur ce fil de discussion.
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« le: 25 Février 2008, 00:43:01 »

Salut à tous, j'essaye de faire un truc qui ne marche pas avec MySQL. Ma base s'appelle thierz_nasa, et j'ai créé avec cPanel un utilisateur thierz_stat relié à cette base (en plus de l'utilisateur standard thierz, qui fait office d'administrateur tout puissant).

J'ai créé (avec thierz) une procédure stockée nommée stats_add qui me remplit des tables de statistiques. J'aimerais que l'utilisateur thierz_stat puisse exécuter cette procédure stockée :

Erreur

requête SQL:

GRANT EXECUTE ON PROCEDURE thierz_nasa.stats_add TO thierz_stat

MySQL a répondu:
#1370 - grant command denied to user 'thierz'@'localhost' for routine 'thierz_nasa.stats_add'


Dingue, non ? Comme si mon utilisateur thierz tout puissant n'était pas assez balaise pour donner le droit à quelqu'un d'autre d'exécuter sa procédure stockée. Avez-vous une idée SVP ? Huh
Journalisée
Forums Webou.net - Hébergement gratuit et sans publicités avec PHP/MySQL
« le: 25 Février 2008, 00:43:01 »

 Journalisée
Arkhena
Bavard
***
Hors ligne Hors ligne

Messages: 232



Voir le profil
« Répondre #1 le: 25 Février 2008, 12:57:07 »

Bonjour MONSIEUR Thierz !  Clin d'oeil

Pourquoi ne pas essayer un simple statement CALL nom_proc(arg1,arg2,...) ?

A priori si c'est un super user, il a déjà les droits, non?
mais bon je peux avoir totalement faux comme d'habitude....

Bonne journée,

Arkhena

Journalisée
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« Répondre #2 le: 25 Février 2008, 22:25:03 »

Bonjour MONSIEUR Thierz !  Clin d'oeil
Arf Clin d'oeil

Merci pour ta réponse. C'est vrai que dans mon message initial, j'oublie de dire que j'ai déjà testé le CALL. L'utilisateur thierz a le droit de faire un CALL, bien entendu, mais moi je voudrais autoriser un autre utilisateur (en l'occurence thierz_stat) à faire lui aussi un CALL de cette procédure.

Quand j'essaye de faire un CALL avec l'utilisateur thierz_stat, je reçois ce message d'erreur :

Code:
execute command denied to user 'thierz_stat'@'localhost' for routine 'thierz_nasa.stats_add'

En gros il me dit "t'as pas le droit d'executer", et quand j'essaye de donner le droit il me dit "t'as pas le droit de donner le droit"... Indéci
« Dernière édition: 25 Février 2008, 22:27:00 par Thierz » Journalisée
MIkE
Big boss
*****
Hors ligne Hors ligne

Messages: 6 220



Voir le profil WWW
« Répondre #3 le: 26 Février 2008, 14:58:07 »

MONSIEUR, Sourire

Résumons :

- pour une commande, l'utilisateur principal (thierz) OK

- pour la même commande, l'utilisateur créé (thierz_stat) avec tous les privilèges et correctement lié à la BDD, ça marche pas.

C'est bien ça?

Je suis pas du tout pro en MySQL mais les réflexions que j'ai sont :
- je ne suis pas étonné qu'on ne puisse pas changer les droits d'un user en cours de route (pb de sécurité)
- je suis étonné qu'un user_sql qui aurait tous les droits ne puisse pas éxécuter une requête que l'user principal exécute sans problème.
Journalisée

Le support et les demandes se font sur le forum. Aucune réponse n'est apportée aux demandes par message privé.
Soutenez Webou en souscrivant à une offre
Arkhena
Bavard
***
Hors ligne Hors ligne

Messages: 232



Voir le profil
« Répondre #4 le: 26 Février 2008, 16:25:50 »

GRANT EXECUTE ON PROCEDURE thierz_nasa.stats_add TO thierz_stat

MySQL a répondu:
#1370 - grant command denied to user 'thierz'@'localhost' for routine 'thierz_nasa.stats_add'


Tu peux peut-être essayer avec des quotes, je ne pense pas que le underscore soit considéré comme caractère spécial, mais on ne sait jamais. Je te conseille également d'ajouter explicitement le nom de la base de données :

GRANT EXECUTE ON PROCEDURE thierz_nasa.stats_add TO 'thierz_stat'@'localhost'

D'autre part, j'ai lu sur http://dev.mysql.com/doc/refman/5.0/en/grant.html que cette syntaxe n'est autorisée qu'à partir de la version 5.0.6 de MySQL, mais je crois que nous sommes en 5.0.45.
Journalisée
Forums Webou.net - Hébergement gratuit et sans publicités avec PHP/MySQL
« Répondre #4 le: 26 Février 2008, 16:25:50 »

 Journalisée
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« Répondre #5 le: 26 Février 2008, 22:28:12 »

Tu peux peut-être essayer avec des quotes, je ne pense pas que le underscore soit considéré comme caractère spécial, mais on ne sait jamais. Je te conseille également d'ajouter explicitement le nom de la base de données
Bonne idée, mais le message d'erreur est le même...

- je ne suis pas étonné qu'on ne puisse pas changer les droits d'un user en cours de route (pb de sécurité)
Je ne suis pas vraiment "en cours de route", le GRANT n'est pas une commande que j'exécute dynamiquement : au contraire, je voudrais l'exécuter une bonne fois pour toutes sur mon utilisateur thierz_stat, depuis phpmyadmin, pour être tranquille par la suite.

Je continue à creuser.
Journalisée
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« Répondre #6 le: 26 Février 2008, 23:12:10 »

Hum, je crois que j'ai trouvé le problème, mais si c'est bien ce que je pense, je ne vais pas pouvoir le résoudre sans le concours des admins de Webou Grimaçant

Je vous expose ma théorie. Voici une commande que j'exécute avec mon utilisateur principal thierz :

Code:
show grants

Cette commande permet de voir les droits dont dispose l'utilisateur. Voici le résultat :

Code:
GRANT USAGE ON *.* TO 'thierz'@'localhost' IDENTIFIED BY PASSWORD 'mon password codé'
GRANT ALL PRIVILEGES ON `thierz\_nasa`.* TO 'thierz'@'localhost'

Interprétation du résultat : la première ligne dit que je n'ai aucun droit sur les bases MySQL des autres utilisateurs Webou (ce qui est tout-à-fait logique), la seconde dit que j'ai tous les droits sur ma propre base MySQL, ce qui est tout-à-fait logique aussi. Vraiment tous les droits ? NON ! En effet, comme le stipule la doc MySQL 5.0 :

Citation
ALL [PRIVILEGES]    Tous les droits sauf WITH GRANT OPTION.

Et ce fameux WITH GRANT OPTION, lui, voilà à quoi il sert :

Citation
La clause WITH GRANT OPTION donne à l'utilisateur le droit de donner les droits qu'il possède à d'autres utilisateurs. La plus grande prudence est recommandée pour cette commande, car il permettra à terme à deux utilisateurs de combiner les droits dont ils disposent.

Vous ne pouvez pas donner un droit que vous ne possédez pas. le droit de GRANT OPTION ne vous donne le droit que de donner les droits que vous possédez.

En bref : mon utilisateur principal ne peut pas transmettre à un autre utilisateur ses propres droits... Ce qui est gênant pour mon cas personnel Indéci

Pour que mon utilisateur thierz puisse donner des droits à thierz_stat, il aurait fallu que ses privilèges soient :

Code:
GRANT USAGE ON *.* TO 'thierz'@'localhost' IDENTIFIED BY PASSWORD 'mon password codé'
GRANT ALL PRIVILEGES ON `thierz\_nasa`.* TO 'thierz'@'localhost' WITH GRANT OPTION

Voilà. Je ne sais pas ce que vous pensez de ma théorie, mais pour moi elle tient bien debout. Maintenant je voudrais savoir : est-il possible que mon utilisateur thierz soit doté du WITH GRANT OPTION, sachant que de toutes façons, je ne vais surtout pas m'amuser à distribuer des droits à quiconque sur ma propre base ? Je suis plutôt du genre parano, et je ne suis pas un Mickey en bases de données : je me limiterai strictement à propager mes droits sur mes propres utilisateurs (comme thierz_stat dans mon exemple).

Si vous vous demandez pourquoi je fais tout ce bazar avec les utilisateurs, je vous répondrai ceci : la sécurité étant mon principal soucis, je suis TRES TRES réticent à mettre en lisible dans mon code PHP le nom et le mot de passe de mon utilisateur MySQL principal. En utilisant des utilisateurs "secondaires" dans mes scripts PHP, dotés de droits très limités sur ma base, je ne cours pas le risque que mon utilisateur principal soit piraté, et ma base détruite, c'est aussi simple que ça. Notez qu'ici je parle de scripts PHP, mais dans un avenir tout proche, je compte également utiliser mes comptes secondaires depuis un programme C#, que je pourrais distribuer en opensource : hors de question donc de laisser le C# se connecter avec l'utilisateur principal.

Voilà, j'espère que ce long plaidoyer vous aura ému aux larmes Clin d'oeil et que vous examinerez ma requête avec attention...

En vous remerciant... bonsoir Sourire
Journalisée
MIkE
Big boss
*****
Hors ligne Hors ligne

Messages: 6 220



Voir le profil WWW
« Répondre #7 le: 27 Février 2008, 10:58:20 »

Hello Monsieur,

J'ai modifié les droits de thierz_stat qui peut "exécuter" maintenant. Clin d'oeil

Reste à savoir pourquoi par défaut ce droit n'est pas accordé aux users mysql et bien au user principal.
Journalisée

Le support et les demandes se font sur le forum. Aucune réponse n'est apportée aux demandes par message privé.
Soutenez Webou en souscrivant à une offre
Arkhena
Bavard
***
Hors ligne Hors ligne

Messages: 232



Voir le profil
« Répondre #8 le: 27 Février 2008, 13:30:06 »

Si vous vous demandez pourquoi je fais tout ce bazar avec les utilisateurs, je vous répondrai ceci : la sécurité étant mon principal soucis, je suis TRES TRES réticent à mettre en lisible dans mon code PHP le nom et le mot de passe de mon utilisateur MySQL principal. En utilisant des utilisateurs "secondaires" dans mes scripts PHP, dotés de droits très limités sur ma base, je ne cours pas le risque que mon utilisateur principal soit piraté, et ma base détruite, c'est aussi simple que ça. Notez qu'ici je parle de scripts PHP, mais dans un avenir tout proche, je compte également utiliser mes comptes secondaires depuis un programme C#, que je pourrais distribuer en opensource : hors de question donc de laisser le C# se connecter avec l'utilisateur principal.

Salut!

De toutes façons, je te déconseille également de fournir dans un code open source les identifiants de ton utilisateur thierz_stat même s'il n'est pas tout puissant.
En C#, je te conseille de mettre les identifiants de connexion à ta base dans un fichier xml. Il suffit que tu ne publies pas ce fichier mais un fichier générique à la place que chaque utilisateur devrait pouvoir configurer.
Pour PHP, doit y avoir moyen de faire un truc similaire.

Bonne journée,

Arkhena
Journalisée
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« Répondre #9 le: 27 Février 2008, 13:53:13 »

J'ai modifié les droits de thierz_stat qui peut "exécuter" maintenant. Clin d'oeil
OK merci beaucoup, je teste ça dès ce soir Grimaçant
Journalisée
K@cem
Never trust user input
Big boss
*****
Hors ligne Hors ligne

Messages: 2 724



Voir le profil WWW
« Répondre #10 le: 27 Février 2008, 18:37:14 »

Je pense que tu ne pourra pas utiliser ta BDD dans un autre programme (C#, C ...) !
J'ai déjà essayé avec C, mais ça n'as pas marché il faut autoriser l'utilisation de mysql à distance Clin d'oeil
Journalisée

Le support ne se fait pas par MP, merci de le respecter !
Thierz
MONSIEUR
Habitué
**
Hors ligne Hors ligne

Messages: 85


Voir le profil WWW
« Répondre #11 le: 27 Février 2008, 21:30:33 »

OK merci beaucoup, je teste ça dès ce soir Grimaçant
Ca marche, merci MIkE ! Souriant
Au besoin, je vous redemanderai de temps en temps de me donner un droit par-ci par-là !

Je pense que tu ne pourra pas utiliser ta BDD dans un autre programme (C#, C ...) !
J'ai déjà essayé avec C, mais ça n'as pas marché il faut autoriser l'utilisation de mysql à distance Clin d'oeil
Argh ! Choqué
Bon, tant pis, je ferai autrement...
Journalisée
Pages: [1]   Haut de page
  Imprimer  
 
Aller à:  

Propulsé par MySQL Propulsé par PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines

Dilber MC Theme by HarzeM
Page générée en 0.039 secondes avec 21 requêtes.