MySQL : changer le propriétaire d'une base

Otomatic

23/06/2013 à 16:58

Eric Demeester écrivait :

J'ai une base 'toto' qui appartient à l'utilisateur 'eric'.

AMHA, on ne peut pas dire qu'une base « appartient » à un utilisateur,
mais plutôt qu'un utilisateur détient les droits nécessaires
(privilèges) pour utiliser et/ou modifier une base de données.
En son temps, j'avais commis un petit topo sur les utilisateurs MySQL
http://fluxbb.fr/aide/doku.php?id=mysql_gestion_utilisateurs

Pour diverses raisons, je souhaite changer le propriétaire de cette base, ou
ajouter un utilisateur autorisé à y accéder.

On va donc créer un nouvel utilisateur qui n'aura le droit d'accéder
qu'à une base de données (On pourrait même limiter à une ou plusieurs
tables).
Pour ce faire, j'utilise PhpMyAdmin (Chez moi en version 4.0.4) en étant
connecté en tant que root.
- Onglet Utilisateur, Ajouter un utilisateur
Nom : tartempion
Client : localhost
Mot de passe : deux fois

et ne rien cocher d'autre : AUCUN privilège global

- Bouton Exécuter
- Recharger les privilèges (Par acquit de conscience)

Utilisateur tartempion -> Changer les privilèges
- AUCUN privilège global
- Privilèges spécifiques à une base de données
-- Choisir le base dans le menu déroulant
-- Il y a rafraîchissement automatique de la fenêtre qui devient :
Changer les privilèges: Utilisateur 'tartempion'@'localhost' - Base de
données xxxx
--- À ce moment choisir les privilèges spécifiques pour cet utilisateur
selon qu'il doit accéder (SELECT) et/ou modifier (INSERT, UPDATE,
DELETE) les données.
--- Choisir, si nécessaire, les privilèges de modification de la
structure.
--- Bouton Exécuter

Quitter PhpMyAdmin.

Se connecter à PhpMyAdmin en tant que utilisateur tartempion
nouvellement créé pour vérifier qu'il a bien accès uniquement à la base
définie.

--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.net
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr

Eric Demeester <neuneu@grosnaze.org.invalid> écrivait :

J'ai une base 'toto' qui appartient à l'utilisateur 'eric'.

AMHA, on ne peut pas dire qu'une base « appartient » à un utilisateur,
mais plutôt qu'un utilisateur détient les droits nécessaires
(privilèges) pour utiliser et/ou modifier une base de données.
En son temps, j'avais commis un petit topo sur les utilisateurs MySQL
http://fluxbb.fr/aide/doku.php?id=mysql_gestion_utilisateurs

Pour diverses raisons, je souhaite changer le propriétaire de cette base, ou
ajouter un utilisateur autorisé à y accéder.

On va donc créer un nouvel utilisateur qui n'aura le droit d'accéder
qu'à une base de données (On pourrait même limiter à une ou plusieurs
tables).
Pour ce faire, j'utilise PhpMyAdmin (Chez moi en version 4.0.4) en étant
connecté en tant que root.
- Onglet Utilisateur, Ajouter un utilisateur
Nom : tartempion
Client : localhost
Mot de passe : deux fois

et ne rien cocher d'autre : AUCUN privilège global

- Bouton Exécuter
- Recharger les privilèges (Par acquit de conscience)

Utilisateur tartempion -> Changer les privilèges
- AUCUN privilège global
- Privilèges spécifiques à une base de données
-- Choisir le base dans le menu déroulant
-- Il y a rafraîchissement automatique de la fenêtre qui devient :
Changer les privilèges: Utilisateur 'tartempion'@'localhost' - Base de
données xxxx
--- À ce moment choisir les privilèges spécifiques pour cet utilisateur
selon qu'il doit accéder (SELECT) et/ou modifier (INSERT, UPDATE,
DELETE) les données.
--- Choisir, si nécessaire, les privilèges de modification de la
structure.
--- Bouton Exécuter

Quitter PhpMyAdmin.

Se connecter à PhpMyAdmin en tant que utilisateur tartempion
nouvellement créé pour vérifier qu'il a bien accès uniquement à la base
définie.

--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.net
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr

Vous avez filtré cet utilisateur ! Consultez son message

Eric Demeester

25/06/2013 à 02:13

Otomatic (Sun, 23 Jun 2013 16:58:39 +0200 - fr.comp.applications.sgbd) :

Bonsoir,

AMHA, on ne peut pas dire qu'une base « appartient » à un utilisateur,
mais plutôt qu'un utilisateur détient les droits nécessaires
(privilèges) pour utiliser et/ou modifier une base de données.

Toutafé, je m'étais mal exprimé.

On va donc créer un nouvel utilisateur qui n'aura le droit d'accéder
qu'à une base de données (On pourrait même limiter à une ou plusieurs
tables).

Jusque là, j'y étais arrivé.

Utilisateur tartempion -> Changer les privilèges

C'est ici que je n'avais pas les yeux en face des trous :

- AUCUN privilège global

Certes.

- Privilèges spécifiques à une base de données
-- Choisir le base dans le menu déroulant

Je n'avais pas vu le menu déroulant :(

--- À ce moment choisir les privilèges spécifiques pour cet utilisateur
selon qu'il doit accéder (SELECT) et/ou modifier (INSERT, UPDATE,
DELETE) les données.

Après, je suis revenu en terrain connu. C'était la maudite liste
déroulante permettant de sélectionner les bases de données que j'avais
zappée.

Se connecter à PhpMyAdmin en tant que utilisateur tartempion
nouvellement créé pour vérifier qu'il a bien accès uniquement à la base
définie.

En fait, Tartempion a accès à 4 bases, et quand il se connecte sur le
phpMyAdmin avec son identifiant et son mot de passe, il ne voit bien que
ses bases à lui qu'il a.

Donc tout baigne, et je te dois une bière :)

Question subsidiaire, est-il possible que les utilisateurs non autorisés
ne voient pas les bases test et information_schema ?

Pourtant, quand je regarde les utilisateurs autorisés à les manipuler,
en gros il n'y a que root et moi.

(je sens que j'abuse.)

--
Eric

Otomatic

25/06/2013 à 19:32

Eric Demeester écrivait :

Question subsidiaire, est-il possible que les utilisateurs non autorisés
ne voient pas les bases test et information_schema ?

Pourtant, quand je regarde les utilisateurs autorisés à les manipuler,
en gros il n'y a que root et moi.

Je n'ai pas trouvé comment le faire.
Il existe bien une option - vide par défaut - à mettre dans le fichier
config.inc.php :
$cfg['Servers'][$i]['hide_db'] = '';
Pour les informations, voir les commentaires pour cette option dans le
fichier phpmyadmin4.0.4librariesconfig.default.php

J'ai beau mettre :
$cfg['Servers'][$i]['hide_db'] = 'information_schema';

je vois toujours cette base, que je sois connecté "tartempion" ou
"root".
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://aviatechno.net - Les anciens de Vilgénis

Eric Demeester

25/06/2013 à 23:07

Otomatic (Tue, 25 Jun 2013 19:32:41 +0200 - fr.comp.applications.sgbd) :

Bonsoir,

Eric Demeester écrivait :
> Question subsidiaire, est-il possible que les utilisateurs non autorisés
> ne voient pas les bases test et information_schema ?

Je n'ai pas trouvé comment le faire.

Je me sens moins seul.

J'ai beau mettre :
$cfg['Servers'][$i]['hide_db'] = 'information_schema';
je vois toujours cette base, que je sois connecté "tartempion" ou
"root".

Je suppose que l'accès à ces deux bases est un truc en dur dans
phpMyAdmin, et/ou dans MySQL.

Autant pour la base 'test', je m'en fiche un peu, autant pour la base
'information_schema', c'est a priori plus gênant, parce qu'elle est
quand même critique, puisque définissant le comportementglobal de MySQL
sur le serveur, si j'ai bien tout compris.

En même temps, il y a un truc que je n'ai pas testé par manque de temps,
c'est d'en faire un backup et de tenter de la modifier en tant
qu'utilisateur « Tartempion ».

Si ça se trouve, que ce soit en ligne de commande ou via phpMyAdmin, si
ce n'est pas root qui demande, MySQL va couiner qu'on a pas le droit de
toucher à cette base.

PS : pour la bière, ça tient toujours et mon Reply-To: est valide.
juste prévoir un délai éventuel, j'ai des antispam féroces, mais
peu de de choses partent directement à la poubelle (et dans ce
cas, je ne la vide que toutes les 48h, donc rien n'est perdu)

PPS : ecrire directement à eric_at_demeester_point_org évite bien des
déconvenues.

--
Eric

Otomatic

26/06/2013 à 10:29

Eric Demeester écrivait :

> Je n'ai pas trouvé comment le faire.

Je me sens moins seul.

> J'ai beau mettre :
> $cfg['Servers'][$i]['hide_db'] = 'information_schema';
> je vois toujours cette base, que je sois connecté "tartempion" ou
> "root".

J'ai toujours dit que pour résoudre des « problèmes » informatiques, il
fallait être très curieux, voire inquisiteur ou fouineur !

J'ai donc cherché comment PhpMyAdmin traitait cet élément du tableau
$cfg par une recherche multifichiers dans mon éditeur de texte préféré
depuis des lustres UltraEdit et je suis tombé dans le fichier
phpmyadmin4.0.4librariesList_Database.class.php
sur :
foreach ($this->getArrayCopy() as $key => $db) {
if (preg_match('/' . $GLOBALS['cfg']['Server']['hide_db'] . '/', $db))
{
$this->offsetUnset($key);

Ah! preg_match entraîne regex, donc éventuellement syntaxe
particulière...
Qu'à cela ne tienne, j'ai essayé différentes syntaxes et je suis tombé
sur un truc qui semble fonctionner à mettre dans le fichier
config.inc.php :

$cfg['Servers'][$i]['hide_db'] = '^information_schema|test$';

et voilou ! tartempion ne voit plus information_schema

CQFD
--
Les gens que l'on considère comme des fous de travail sont, peut-être,
tout simplement entrain de s'amuser. Einstein

Eric Demeester

27/06/2013 à 21:47

Otomatic (Wed, 26 Jun 2013 10:29:25 +0200 - fr.comp.applications.sgbd) :

Bonsoir, Ô Mon Sauveur,

Qu'à cela ne tienne, j'ai essayé différentes syntaxes et je suis tombé
sur un truc qui semble fonctionner à mettre dans le fichier
config.inc.php :
$cfg['Servers'][$i]['hide_db'] = '^information_schema|test$';

Une dernière question, mais de feignasse parce que je pourrais tout seul
en 5 minutes : le config.inc.php, c'est celui de phpMyAdmin, je
suppose ?

et voilou ! tartempion ne voit plus information_schema

Trop fort.

CQFD

Sur le coup, je te dois plein de bières, et mon adresse est toujours
valide :)

--
Eric

Antoine Polatouche

28/06/2013 à 02:26

Une dernière question, mais de feignasse parce que je pourrais tout seul
en 5 minutes : le config.inc.php, c'est celui de phpMyAdmin, je
suppose ?

et voilou ! tartempion ne voit plus information_schema

Mais comme c'est une option de phpmyadmin, tartempion peut faire une
requête sql SHOW DATABASES et voir test et information_schema…

Otomatic

28/06/2013 à 09:58

Eric Demeester écrivait :

Une dernière question, mais de feignasse parce que je pourrais tout seul
en 5 minutes : le config.inc.php, c'est celui de phpMyAdmin, je
suppose ?

Oui.

Lors de son lancement, PhpMyAdmin va d'abord lire le contenu du fichier
contenant toutes les informations de configuration par défaut :

phpmyadmin4.0.4librariesconfig.default.php

puis ensuite il va lire le contenu de :

phpmyadmin4.0.4config.inc.php

donc, dans ce fichier de configuration personnel
phpmyadmin4.0.4config.inc.php
on ne doit mettre QUE ce qui diffère des informations par défaut qui
viendront donc les « écraser ».
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche

Eric Demeester

28/06/2013 à 16:06

Otomatic (Fri, 28 Jun 2013 09:58:40 +0200 - fr.comp.applications.sgbd) :

Hello,

donc, dans ce fichier de configuration personnel
phpmyadmin4.0.4config.inc.php
on ne doit mettre QUE ce qui diffère des informations par défaut qui
viendront donc les « écraser ».

Si ça peut aider d'autres personnes, voici comment j'ai procédé :

j'ai un peu fouillé pour trouver où était ce fichier sur mon CentOs LTE
[*], et je l'ai trouvé dans :

/etc/phpMyAdmin

Par prudence, j'ai commencé par faire une copie du fichier existant pour
pouvoir revenir en arrière en cas de bétise. Je me méfie énormément de
ma capacité à faire des bétises, l'expérience, toussa :

# cp config.inc.php config.inc_old.php

Ensuite, j'ai édité le fichier config.inc.php comme suit :

// Modif Eric 2013-06-28 : On cache les bases information_schema et test
// $cfg['Servers'][$i]['hide_db'] = ''; // Database name
// to be hidden from listings
$cfg['Servers'][$i]['hide_db'] = '^information_schema|test$';
// Fin modif Eric
<esc>:wq

Bah oui, j'utilise vi en SSH, je suis vieux, j'ai des doigts et je ne
suis pas trop clicodrome compliant.

Redémarrage d'Apache pour prise en compte de la modif :

# apachectl graceful

Enfin, connexion à phpMyAdmin via le navigateur, avec le nom de
l'utilisateur concerné : hop, mission réussie, les deux bases ont
disparu.

Effet de bord, mais peu importe, finalement, elles ne sont plus
accessibles à aucun utilisateur, y-compris root.

On me souffle dans l'oreillette que ça pouvait peut-être se gérer de
façon plus fine et plus propre (sans aller bricoler à la hache dans le
fichier de configuration) via les privilèges associés à chaque user pour
chaque base.

C'est pas faux, à la réflexion, mais bon, comme ça, ça me va bien.

Pour conclure, j'ai fait un test avant de changer la configuration, et
tout cela ne sert à rien, à part satisfaire mon goût immodéré pour les
trucs bien rangés.

En effet, si information_schema est (enfin, était) lisible et visible
par tous les comptes, aucun ne peut changer son contenu, et c'est tant
mieux, parce que c'est quand même LA base de données qui détermine le
comportement global de MySQL.

D'où la question subsidiaire, pourquoi cette base est-elle par défaut
accessible en lecture à tous les utilisateurs ? test, à la rigueur, pour
faire des tests (mais le user n'a pas à faire de tests), mais
information_schema ?

Voila voila, au moins j'aurai appris des trucs. Merci Automatic, et
merci Usenet, qui reste, quoiqu'on en dise, souvent pour moi le moyen le
plus rapide et le plus fiable pour obtenir des informations pertinentes.

[*] CentOs LTE, ce n'est peut-être pas très sexy comme distribution, et
plutôt dépouillé (surtout quand on ne fait qu'une installation
minimale et qu'on n'ajoute au fur et à mesure que les applis dont on
a besoin), mais sur un serveur en prod, c'est assez sécurisant
d'utiliser un OS stable dont on sait qu'il sera maintenu plusieurs
années.

Aucun souci de mise à jour non plus, puisqu'un cron quotidien va les
chercher (OS et applications) et les installe en silence.

--
Eric

Otomatic (Fri, 28 Jun 2013 09:58:40 +0200 - fr.comp.applications.sgbd) :

Hello,

donc, dans ce fichier de configuration personnel
phpmyadmin4.0.4config.inc.php
on ne doit mettre QUE ce qui diffère des informations par défaut qui
viendront donc les « écraser ».

Si ça peut aider d'autres personnes, voici comment j'ai procédé :

j'ai un peu fouillé pour trouver où était ce fichier sur mon CentOs LTE
[*], et je l'ai trouvé dans :

/etc/phpMyAdmin

Par prudence, j'ai commencé par faire une copie du fichier existant pour
pouvoir revenir en arrière en cas de bétise. Je me méfie énormément de
ma capacité à faire des bétises, l'expérience, toussa :

# cp config.inc.php config.inc_old.php

Ensuite, j'ai édité le fichier config.inc.php comme suit :

// Modif Eric 2013-06-28 : On cache les bases information_schema et test
// $cfg['Servers'][$i]['hide_db'] = ''; // Database name
// to be hidden from listings
$cfg['Servers'][$i]['hide_db'] = '^information_schema|test$';
// Fin modif Eric
<esc>:wq

Bah oui, j'utilise vi en SSH, je suis vieux, j'ai des doigts et je ne
suis pas trop clicodrome compliant.

Redémarrage d'Apache pour prise en compte de la modif :

# apachectl graceful

Enfin, connexion à phpMyAdmin via le navigateur, avec le nom de
l'utilisateur concerné : hop, mission réussie, les deux bases ont
disparu.

Effet de bord, mais peu importe, finalement, elles ne sont plus
accessibles à aucun utilisateur, y-compris root.

On me souffle dans l'oreillette que ça pouvait peut-être se gérer de
façon plus fine et plus propre (sans aller bricoler à la hache dans le
fichier de configuration) via les privilèges associés à chaque user pour
chaque base.

C'est pas faux, à la réflexion, mais bon, comme ça, ça me va bien.

Pour conclure, j'ai fait un test avant de changer la configuration, et
tout cela ne sert à rien, à part satisfaire mon goût immodéré pour les
trucs bien rangés.

En effet, si information_schema est (enfin, était) lisible et visible
par tous les comptes, aucun ne peut changer son contenu, et c'est tant
mieux, parce que c'est quand même LA base de données qui détermine le
comportement global de MySQL.

D'où la question subsidiaire, pourquoi cette base est-elle par défaut
accessible en lecture à tous les utilisateurs ? test, à la rigueur, pour
faire des tests (mais le user n'a pas à faire de tests), mais
information_schema ?

Voila voila, au moins j'aurai appris des trucs. Merci Automatic, et
merci Usenet, qui reste, quoiqu'on en dise, souvent pour moi le moyen le
plus rapide et le plus fiable pour obtenir des informations pertinentes.

[*] CentOs LTE, ce n'est peut-être pas très sexy comme distribution, et
plutôt dépouillé (surtout quand on ne fait qu'une installation
minimale et qu'on n'ajoute au fur et à mesure que les applis dont on
a besoin), mais sur un serveur en prod, c'est assez sécurisant
d'utiliser un OS stable dont on sait qu'il sera maintenu plusieurs
années.

Aucun souci de mise à jour non plus, puisqu'un cron quotidien va les
chercher (OS et applications) et les installe en silence.

--
Eric

Vous avez filtré cet utilisateur ! Consultez son message

Otomatic (Fri, 28 Jun 2013 09:58:40 +0200 - fr.comp.applications.sgbd) :

Hello,

donc, dans ce fichier de configuration personnel
phpmyadmin4.0.4config.inc.php
on ne doit mettre QUE ce qui diffère des informations par défaut qui
viendront donc les « écraser ».

Si ça peut aider d'autres personnes, voici comment j'ai procédé :

j'ai un peu fouillé pour trouver où était ce fichier sur mon CentOs LTE
[*], et je l'ai trouvé dans :

/etc/phpMyAdmin

Par prudence, j'ai commencé par faire une copie du fichier existant pour
pouvoir revenir en arrière en cas de bétise. Je me méfie énormément de
ma capacité à faire des bétises, l'expérience, toussa :

# cp config.inc.php config.inc_old.php

Ensuite, j'ai édité le fichier config.inc.php comme suit :

// Modif Eric 2013-06-28 : On cache les bases information_schema et test
// $cfg['Servers'][$i]['hide_db'] = ''; // Database name
// to be hidden from listings
$cfg['Servers'][$i]['hide_db'] = '^information_schema|test$';
// Fin modif Eric
<esc>:wq

Bah oui, j'utilise vi en SSH, je suis vieux, j'ai des doigts et je ne
suis pas trop clicodrome compliant.

Redémarrage d'Apache pour prise en compte de la modif :

# apachectl graceful

Enfin, connexion à phpMyAdmin via le navigateur, avec le nom de
l'utilisateur concerné : hop, mission réussie, les deux bases ont
disparu.

Effet de bord, mais peu importe, finalement, elles ne sont plus
accessibles à aucun utilisateur, y-compris root.

On me souffle dans l'oreillette que ça pouvait peut-être se gérer de
façon plus fine et plus propre (sans aller bricoler à la hache dans le
fichier de configuration) via les privilèges associés à chaque user pour
chaque base.

C'est pas faux, à la réflexion, mais bon, comme ça, ça me va bien.

Pour conclure, j'ai fait un test avant de changer la configuration, et
tout cela ne sert à rien, à part satisfaire mon goût immodéré pour les
trucs bien rangés.

En effet, si information_schema est (enfin, était) lisible et visible
par tous les comptes, aucun ne peut changer son contenu, et c'est tant
mieux, parce que c'est quand même LA base de données qui détermine le
comportement global de MySQL.

D'où la question subsidiaire, pourquoi cette base est-elle par défaut
accessible en lecture à tous les utilisateurs ? test, à la rigueur, pour
faire des tests (mais le user n'a pas à faire de tests), mais
information_schema ?

Voila voila, au moins j'aurai appris des trucs. Merci Automatic, et
merci Usenet, qui reste, quoiqu'on en dise, souvent pour moi le moyen le
plus rapide et le plus fiable pour obtenir des informations pertinentes.

[*] CentOs LTE, ce n'est peut-être pas très sexy comme distribution, et
plutôt dépouillé (surtout quand on ne fait qu'une installation
minimale et qu'on n'ajoute au fur et à mesure que les applis dont on
a besoin), mais sur un serveur en prod, c'est assez sécurisant
d'utiliser un OS stable dont on sait qu'il sera maintenu plusieurs
années.

Aucun souci de mise à jour non plus, puisqu'un cron quotidien va les
chercher (OS et applications) et les installe en silence.

--
Eric

noreply

15/07/2013 à 15:22

SaluÅ£

je deterre un peu le sujet pour y apporter ma contribution.

Antoine Polatouche writes:

Une derniÃ¨re question, mais de feignasse parce que je pourrais tout seul
en 5 minutes : le config.inc.php, c'est celui de phpMyAdmin, je
suppose ?

et voilou ! tartempion ne voit plus information_schema

Mais comme c'est une option de phpmyadmin, tartempion peut faire une
requÃªte sql SHOW DATABASES et voir test et information_schemaâ ¦

Personnelement, je fais diffÃ©remment.

Dans le service oÃ¹ je travaille, je crÃ©Ã© un utilisateur toto qui ne
pourra voir/agir que sur une base "toto+".

Voici comment je procÃ¨de:

GRANT USAGE ON *.* TO toto@<host> IDENTIFIED BY password('motdepasse');
INSERT INTO mysql.db (Host, Db, User, Select_priv,
Insert_priv,Update_priv, Delete_priv,
Create_priv, Drop_priv, Grant_priv,
References_priv,
Index_priv, Alter_priv, Create_tmp_table_priv,Lock_tab les_priv)
VALUES ('<host>','toto%','toto','Y', 'Y', 'Y', 'Y','Y', 'Y', 'N', 'Y', 'Y', 'Y', 'Y', 'Y');
FLUSH PRIVILEGES;

Grant n'acceptant pas (dans les versions que j'ai pu testÃ©es) de
caractÃ¨res gÃ©nÃ©riques, il faut passer par des commandes plus "roots".

Cordialement
--
XMA

MySQL : changer le propriétaire d'une base

10 réponses

Veuillez sélectionner un problème