Utiliser mysqldump dans un travail cron sans mot de passe root

14

Si je me connecte avec le mot de passe root sur ma boîte, je peux simplement taper

mysqldump --all-databases et j'obtiendrai le "Dump" attendu.

J'ai configuré un travail dans cron.daily pour l'exécuter et le vider sur un lecteur de sauvegarde. Le problème que j'ai est que, bien que l'utilisateur s'exécute en tant que root, j'obtiens le message suivant

mysqldump: Erreur obtenue: 1045: Accès refusé pour l'utilisateur 'root' @ 'localhost' (en utilisant le mot de passe: NO)

lorsque vous essayez de vous connecter. Je ne veux pas coder en dur le mot de passe root de la base de données mysql dans le script (qui le ferait).

Étant donné que je peux simplement taper "mysqldump" sur la ligne de commande dans mon shell bash, il doit y avoir un moyen de se déplacer en utilisant le paramètre -u. J'ai déjà #! / Bin / bash en haut du script.

Qu'est-ce que je manque ici pour que cela ne demande pas le mot de passe root à la base de données?

mysql scripting cron

— Logiciel Mech
source

12

Pour vous connecter au serveur mysql, vous devez fournir des informations d'identification. Vous pouvez les spécifier dans un fichier de configuration, les transmettre via la ligne de commande ou simplement créer un compte qui ne nécessite pas d'informations d'identification.

Bien sûr, l'option sans mot de passe ne doit jamais être utilisée, la ligne de commande de passage n'est pas géniale car quiconque peut exécuter ps peut voir la ligne de commande.

L'option recommandée consiste à créer un fichier de configuration mysql avec les informations d'identification, puis à protéger ce fichier avec des autorisations de système de fichiers afin que seul votre utilisateur de sauvegarde puisse y accéder.

Vous pouvez vous connecter au serveur mysql lorsque vous êtes connecté de manière interactive en tant que root semble suggérer que vous n'avez pas de mot de passe root défini ou que vous avez un fichier de configuration qui n'est pas trouvé par votre script. Si vous avez un .my.cnf, vous devrez peut-être le pointer manuellement. Si votre compte root n'a pas de mot de passe, je vous encourage fortement à le corriger.

Mise à jour (2016-06-29) Si vous exécutez mysql 5.6.6 ou une version ultérieure, vous devez consulter l' outil mysql_config_editor qui vous permet de stocker les informations d'identification dans un fichier crypté. Merci à Giovanni de m'en avoir parlé.

— Zoredache
source

1

Cette méthode nécessite toujours un mot de passe non chiffré en texte brut pour être sur le système. C'est ce que j'essaie d'éviter.

— Mech Software

> soit vous n'avez pas de mot de passe root, soit vous avez un fichier de configuration qui n'est pas trouvé par votre script. L'auteur indique clairement qu'il existe un mot de passe mysql pour root et qu'il essaie d'accéder à la base de données sans le fournir à la commande mysqldump: "(en utilisant le mot de passe: NO)". D'où l'erreur d'accès refusé.

— monomyth

1

@monomyth, l'auteur déclare également qu'il peut se connecter sans mot de passe tout en étant connecté en tant qu'utilisateur root. Cela me dit que quelque chose ne va pas.

— Zoredache

2

@Mech Software, il ne sert à rien d'essayer de vous protéger du compte root. Si quelqu'un a le compte root, il peut simplement redémarrer le mysql et contourner complètement le système d'autorisation.

— Zoredache

1

La raison pour laquelle j'ai pu me connecter était que le compte root avait un .my.cnf spécifié avec 600 autorisations, c'est donc ainsi que le shell obtenait l'accès. cron cependant, doit ignorer le fichier, j'ai donc utilisé le paramètre dans ce post pour le désigner.

— Mech Software

3

La sécurité ne doit pas se faire par l'obscurité. Si vous avez peur que quelqu'un ait accès à votre compte root, peu importe si le mot de passe mysql de root est stocké dans le script, car toutes vos données sont disponibles dans les vidages mysql ou les fichiers de base de données. Alors, la vraie question est ce que vous essayez de protéger?

Si vous ne voulez pas que les autres obtiennent un mot de passe qui leur permettra de modifier les données de votre base de données, vous devrez créer un utilisateur avec les autorisations appropriées .

Si vous ne voulez pas que ce mot de passe mysql soit vu par un compte local, à l'exception des autorisations de fichier de jeu de racine sur ce script à 0700 et le propriétaire à root.

— monomyth
source

1

Je suppose que ce que je ne comprends toujours pas, c'est que si je peux taper (à partir de l'invite root) mysqldump sans saisie de mot de passe, pourquoi ne puis-je pas l'exécuter via le travail cron de la même manière. Quelle pièce manque qui nécessite le paramètre -p. Je n'essaye pas de "masquer" le mot de passe, je préfère simplement ne jamais le saisir. Quelque chose de particulier à la connexion root elle-même permet l'accès, alors pourquoi ne pas le répliquer avec cron?

— Mech Software

Si vous voyez que vous pouvez vous connecter sans mot de passe et avec un mot de passe en utilisant le même utilisateur "root", il est possible qu'il y ait plusieurs utilisateurs root dans votre base de données mysql. Certains d'entre eux n'ont peut-être pas de mot de passe défini. Vous pouvez supprimer le mot de passe de la «racine» @ «localhost», mais non seulement cron pourra se connecter à votre base de données, mais toute personne possédant un compte local. Ce n'est pas différent (ou pire) que d'avoir un mot de passe dans un script en texte clair.

— monomyth

Je pense que le fait est que MechSoftware faisait que le fait d'être root vous donne essentiellement un accès en lecture aux fichiers de base de données, et ils ne sont pas cryptés. Par conséquent, exiger le mot de passe root MySQL de l'utilisateur root uniquement pour imprimer les données auxquelles il peut déjà accéder est «la sécurité par l'obscurité». En outre, les autorisations sont très faciles à gâcher, par exemple si quelqu'un les définit récursivement pour un répertoire, s'il y a un lien symbolique vers le fichier, etc.

— Septagram

2

Votre utilisation du shell peut le faire car vous avez un shell pour l'exécuter, c'est-à-dire lorsque vous vous connectez, tous vos scripts shell de votre profil sont exécutés.

Cron n'a pas de tels luxes. Lorsqu'il se connecte (en tant que root), il se connecte avec un shell par défaut. Cela empêche quiconque de se connecter à distance, mais cela signifie également qu'aucun script de connexion automatique n'est exécuté.

Vous pouvez définir un shell pour que cron s'exécute sous, modifier la crontab et ajouter les variables SHELL et HOME, par exemple.

SHELL=/bin/bash
HOME=/root

s'ils ne sont pas définis, alors cron s'exécutera avec le shell et le répertoire personnel spécifiés dans / etc / passwd (qui ne sont probablement rien, peut-être / bin / sh).

Si vous voulez voir l'environnement dans lequel cron s'exécute, ajoutez un travail cron qui exporte env dans un fichier, par exemple:

$crontab -e
* * * * * env > /tmp/crontabenv.log
:wq

— gbjbaanb
source

1

Si le script est exécuté par root, vous pouvez créer un fichier /root/.my.cnf avec les autorisations 600 et le contenu suivant:

[client]
user = DBUSERNAME
password = DBPASSWORD

(où vous entrez bien sûr votre nom d'utilisateur et votre mot de passe MySQL).

Ce fichier sera automatiquement lu par n'importe quel outil de ligne de commande mysql, s'il est exécuté en tant que root. Plus besoin de le fournir sur la ligne de commande. Les 600 autorisations le protègent contre les regards indiscrets.

— Martijn Heemels
source

1

J'ai trouvé que c'était le cas de COMMENT j'ai pu nous mysqldump sans le mot de passe. Donc, cela a résolu le mystère de la façon dont le SHELL le fait, alors pourquoi Cron ne le lit pas?

— Mech Software

1

mysqldump lors de l'exécution à partir de cron peut ne pas être en mesure de localiser le fichier .my.cnf. Le remède consiste à ajouter un paramètre mysqldump pour lire explicitement les options du fichier.my.cnf, c'est-à-dire --defaults-extra-file = / root / .my.cnf. J'ai appris cela de deux autres réponses sur Stack Overflow. Voir stackoverflow.com/a/602054/854680 et stackoverflow.com/a/890554/854680

— MikeOnline

1

Cron peut être très frustrant à déboguer. Lorsque les tâches cron s'exécutent, aucun environnement n'est défini comme vous le tenez pour acquis avec un shell.

Conseils pour cron:

utiliser des chemins complets vers tout - "ECHO = / bin / echo", etc: (définir des variables en haut pour le rendre plus facile)
définissez MAILTO, de sorte que vous recevez un e-mail de chaque travail (ou que les travaux redirigent stderr / stdout vers un fichier)

Si votre utilisateur root peut le faire à partir du shell, cron devrait pouvoir le faire. Assurez-vous de spécifier explicitement le fichier de configuration à utiliser sur la ligne de commande.

0

Bien que plusieurs de ces réponses soient utiles, plusieurs prêtent à confusion car l'utilisateur root unix et l'utilisateur root mysql ne sont pas les mêmes et n'ont fondamentalement aucune relation autre qu'ils utilisent tous les deux le nom de connexion 'root'. C'est peut-être évident, mais il semble que certaines réponses confondent les deux.

Ce qui pourrait être une option utile (peut-être existe-t-elle?) Pour mysqld serait d'autoriser des programmes clients tels que mysql ou mysqldump etc fonctionnant en tant que root unix à accéder à root @ localhost de mysqld sans mot de passe sans avoir à stocker le mot de passe de root @ localhost (mysql) dans un fichier my.cnf ou similaire.

Je sais que cela rend un peu nerveux mais le raisonnement est que n'importe qui s'exécutant en tant que racine unix locale (sur le serveur mysqld) peut contourner la sécurité de mysqld de toute façon, assez facilement. Et avoir un my.cnf avec le mot de passe root mysqld 7x24 ou même créer / supprimer un my.cnf avec le mot de passe root mysql (d'où vient ce mot de passe?) À la volée (par exemple, pour faire un mysqldump) fait me nerveux.

Cela nécessiterait une certaine infrastructure et une réflexion car il faudrait faire confiance à mysql / mysqldump / etc pour transmettre à mysqld qu'il croit vraiment qu'il est géré par un compte root unix local.

Mais par exemple, limiter uniquement à la socket Unix de mysqld, aucun TCP, pourrait au moins être une option fortement recommandée de cette option. Cela pourrait établir que le client fonctionne localement, ce qui n'est probablement pas tout à fait suffisant. Mais cela pourrait être le début d'une idée. Peut-être que l'envoi d'un descripteur de fichier sur un socket Unix pourrait être un autre élément (google si cela ressemble à un discours fou.)

PS Non, je ne vais pas essayer de réfléchir ici comment tout cela pourrait fonctionner sur un système d'exploitation non-unix, alors que l'idée se traduit probablement par d'autres systèmes d'exploitation.

— Barry Shein
source

1

Mettre les informations d'identification /root/.my.cnfavec les autorisations appropriées résout parfaitement le problème.

— Michael Hampton

Je ne suis pas d'accord, maintenant quiconque peut accéder à ce fichier, y compris via une autre faille du système, a la racine mysql pw. Et il est là 24 heures sur 24, 7 jours sur 7, pour être attaqué, et dans un emplacement de fichier fixe (mais il ne devrait pas nécessairement être dans / root.) Mais par exemple, quiconque exécute des vidages du système de fichiers, ou peut y accéder, peut le retirer de un fichier de vidage du système de fichiers. Dans ce cas, cela ressemble à une tentation pour un employé mécontent. Je pense que c'est un objectif raisonnable qu'aucun mot de passe en texte clair n'existe sur un système, où que ce soit.

— Barry Shein

Peut-être que oui, mais la proposition que vous avez faite est bien pire, car elle permet à tout utilisateur local de prétendre trivialement être root.

— Michael Hampton

Non, ma proposition était qu'ils doivent déjà être root unix sur le serveur local, auquel cas le mysqld local fait confiance à mysql ou mysqldump etc (client) exécuté en tant que root unix et leur permet de procéder comme s'ils s'étaient authentifiés en tant que racine mysql . Comme je l'ai dit, s'ils sont déjà root unix local sur le serveur, ils peuvent de toute façon contourner le mot de passe root mysql avec quelques commandes bien documentées ("récupération du mot de passe root mysql").

— Barry Shein