Usando mysqldump no cron job sem senha root

14

Se eu entrar com a senha root na minha caixa, posso simplesmente digitar

mysqldump --all-database e eu receberei o esperado "Dump".

Eu configurei um trabalho no cron.daily para executar e despejar isso em uma unidade de backup. O problema que tenho é que, embora o usuário esteja executando como root, recebo a seguinte mensagem

mysqldump: Erro: 1045: Acesso negado para o usuário 'root' @ 'localhost' (usando a senha: NO)

ao tentar se conectar. Eu não quero codificar a senha raiz do banco de dados mysql no script (quem o faria).

Considerando que eu posso apenas digitar "mysqldump" na linha de comando no meu shell do bash, deve haver alguma maneira de contornar o parâmetro -u. Eu já tenho #! / Bin / bash na parte superior do script.

O que estou faltando aqui para fazer com que isso não solicite a senha root ao banco de dados?

mysql scripting cron

— Mech Software
fonte

12

Para se conectar ao servidor mysql, você deve fornecer credenciais. Você pode especificá-los em um arquivo de configuração, transmiti-los pela linha de comando ou simplesmente criar uma conta que não exija credenciais.

É claro que a opção sem senha nunca deve ser usada, a linha de comando de passagem não é ótima porque qualquer pessoa que possa executar o ps poderá ver a linha de comando.

A opção recomendada é criar um arquivo de configuração mysql com as credenciais e, em seguida, proteger esse arquivo com as permissões do sistema de arquivos, para que somente o usuário de backup possa acessá-lo.

Você conseguir fazer login no servidor mysql enquanto estiver conectado interativamente, pois o root parece sugerir que você não possui uma senha de root definida ou que possui um arquivo de configuração que não está sendo encontrado pelo seu script. Se você possui um .my.cnf, pode ser necessário apontar manualmente para ele. Se sua conta root não tiver uma senha definida, recomendamos que você corrija isso.

Atualização (29/06/2016) Se você estiver executando o mysql 5.6.6 ou superior, consulte a ferramenta mysql_config_editor que permite armazenar credenciais em um arquivo criptografado. Agradeço ao Giovanni por mencionar isso para mim.

— Zoredache
fonte

1

Esse método ainda exige que uma senha não criptografada em texto sem formatação esteja no sistema. É isso que estou tentando evitar.

— Mech Software

> você não tem uma senha root definida ou possui um arquivo de configuração que não está sendo encontrado pelo seu script. O autor afirma claramente que existe uma senha do mysql para root e que ele está tentando acessar o banco de dados sem fornecê-lo ao comando mysqldump: "(usando a senha: NO)". Daí o acesso negado.

— monomito

1

@monomyth, o autor também afirma que pode fazer login sem senha enquanto estiver conectado interativamente como root. Isso me diz que algo não está certo.

— Zoredache

2

@Mech Software, Não faz muito sentido tentar se proteger da conta root. Se alguém tiver a conta root, basta reiniciar o mysql e ignorar completamente o sistema de permissões.

— Zoredache

1

A razão pela qual consegui fazer login foi que a conta raiz tinha um .my.cnf especificado com 600 permissões, portanto é assim que o shell estava obtendo acesso. cron, no entanto, deve estar ignorando o arquivo, então usei o parâmetro neste post para apontar para ele.

— Mech Software

3

A segurança não deve ser feita através da obscuridade. Se você tem medo de que alguém tenha acesso à sua conta root, não importa se a senha mysql do root está armazenada no script, pois você tem todos os seus dados disponíveis em despejos do mysql ou arquivos de banco de dados. Então, a verdadeira questão é o que você está tentando proteger?

Se você não quiser que outras pessoas obtenham uma senha que permita alterar dados no seu banco de dados, será necessário criar um usuário com as permissões apropriadas .

Se você não deseja que essa senha do mysql seja vista por qualquer conta local, exceto as permissões de arquivo do conjunto raiz nesse script, para 0700 e o proprietário para raiz.

— monomito
fonte

1

Eu acho que o que ainda não entendo é que, se eu posso digitar (no prompt raiz) mysqldump sem entrada de senha, por que não consigo executá-lo no trabalho cron da mesma maneira? Que peça está faltando e requer o parâmetro -p. Não estou tentando "obscurecer" a senha, prefiro nunca inseri-la. Algo específico para o login root em si está permitindo o acesso, então por que isso não pode ser replicado com o cron?

— Mech Software

Se você perceber que pode fazer login sem uma senha e com uma senha usando o mesmo usuário "root", é possível que haja vários usuários root no seu banco de dados mysql. Alguns deles podem não ter senha definida. Você pode remover a senha do 'root' @ 'localhost', mas não apenas o cron poderá se conectar ao seu banco de dados, mas qualquer pessoa com uma conta local. Isso não é diferente (ou pior) do que ter uma senha em um script de texto não criptografado.

— monomito

Eu acho que o ponto é que a MechSoftware estava fazendo é que ser root essencialmente dá a você acesso de leitura aos arquivos do banco de dados, e eles não são criptografados. Portanto, exigir a senha root do MySQL do usuário root apenas para imprimir os dados que eles essencialmente já podem acessar é "segurança através da obscuridade". Além disso, as permissões são muito fáceis de estragar, por exemplo, se alguém está colocando-os de forma recursiva para um diretório, se há um link simbólico para o arquivo etc.

— Septagram

2

Seu uso de shell pode fazer isso porque você tem um shell para executá-lo, ou seja, quando você faz logon, todos os seus scripts de shell no seu perfil são executados.

Cron não tem esses luxos. Quando ele faz logon (como root), ele faz logon com um shell padrão. Isso impede que alguém faça logon remotamente, mas também significa que não há scripts de logon automático executados.

Você pode configurar um shell para o cron rodar, editar o crontab e adicionar as variáveis SHELL e HOME, por exemplo.

SHELL=/bin/bash
HOME=/root

se estes não estiverem definidos, o cron será executado com o diretório shell e home especificado em / etc / passwd (que provavelmente não são nada, possivelmente / bin / sh).

Se você quiser ver o ambiente em que o cron está sendo executado, adicione um trabalho cron que exporte env para um arquivo, por exemplo:

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

— gbjbaanb
fonte

1

Se o script for executado pela raiz, você poderá criar um arquivo /root/.my.cnf com permissões 600 e o seguinte conteúdo:

[client]
user = DBUSERNAME
password = DBPASSWORD

(onde você digita seu nome de usuário e senha do MySQL, é claro).

Este arquivo será lido automaticamente por qualquer ferramenta de linha de comando do mysql, se for executado como root. Não há mais necessidade de fornecê-lo na linha de comando. As 600 permissões protegem contra olhares indiscretos.

— Martijn Heemels
fonte

1

Eu descobri que este era o caso de COMO eu era capaz de usar o mysqldump sem a senha. Então isso resolveu o mistério de como o SHELL está fazendo isso, então por que o cron não está lendo?

— Mech Software

1

O mysqldump quando executado a partir do cron pode não conseguir localizar o arquivo .my.cnf. O remédio é adicionar um parâmetro mysqldump para ler explicitamente as opções no arquivo.my.cnf, ou seja, --defaults-extra-file = / root / .my.cnf Aprendi isso com outras duas respostas no Stack Overflow. Veja stackoverflow.com/a/602054/854680 e stackoverflow.com/a/890554/854680

— MikeOnline

1

Cron pode ser muito frustrante para depurar. Quando os trabalhos do cron são executados, eles não têm um ambiente definido como você considera garantido com um shell.

Dicas para cron:

use caminhos completos para tudo - "ECHO = / bin / echo", etc: (defina as variáveis na parte superior para facilitar)
defina MAILTO, para que você receba um email de cada trabalho (ou faça com que os trabalhos redirecionem stderr / stdout para um arquivo)

Se o seu usuário root puder fazer isso a partir do shell, o cron poderá fazê-lo. Certifique-se de especificar explicitamente o arquivo de configuração a ser usado na linha de comando.

0

Embora várias dessas respostas sejam úteis, várias são confusas, pois o usuário root do unix e o usuário root do mysql não são os mesmos e basicamente não têm nenhum relacionamento além de ambos usarem o nome de login 'root'. Talvez isso seja óbvio, mas parece que algumas respostas conflitam as duas.

O que poderia ser uma opção útil (talvez exista?) Para o mysqld seria permitir que programas clientes como mysql ou mysqldump etc executando como raiz unix acessassem o root @ localhost do mysqld sem uma senha sem ter que armazenar a senha do root @ localhost (mysql) em um arquivo my.cnf ou similar.

Eu sei que isso fica um pouco nervoso, mas o raciocínio é que qualquer um que esteja executando como raiz unix local (para o servidor mysqld) pode ignorar a segurança do mysqld de qualquer maneira, com bastante facilidade. E ter um my.cnf com a senha root mysqld 7x24 ou até criar / excluir um my.cnf com a senha root mysql (de onde vem essa senha?) Em tempo real (por exemplo, para executar um mysqldump) me deixa nervoso.

Isso exigiria alguma infraestrutura e pensamento, porque seria necessário confiar no mysql / mysqldump / etc para transmitir ao mysqld que ele realmente acredita que está sendo executado por uma conta raiz local do unix.

Mas, por exemplo, limitar apenas o soquete unix do mysqld, sem TCP, poderia ajudar, pelo menos como uma opção fortemente recomendada dessa opção. Isso pode estabelecer que o cliente está sendo executado localmente, o que provavelmente não é suficiente. Mas poderia ser o começo de uma ideia. Talvez o envio de um descritor de arquivo por um soquete unix possa ser outra peça (pesquise no Google se isso soa como uma loucura).

PS Não, não vou tentar discutir aqui como isso pode funcionar em um sistema operacional não-unix, embora a ideia provavelmente se traduza em outros sistemas operacionais.

— Barry Shein
fonte

1

Colocar as credenciais /root/.my.cnfcom as permissões apropriadas resolve o problema.

— Michael Hampton

Eu discordo, agora qualquer pessoa que possa obter acesso a esse arquivo, inclusive através de alguma outra falha do sistema, possui o root mysql pw. E existe 24x7 para ser atacado, e em um local fixo de arquivo (embora não seja necessário que ele esteja no / root.) Mas, por exemplo, quem executa dumps do sistema de arquivos ou pode obter acesso a um pode retirá-lo um arquivo de despejo do sistema de arquivos. Nesse caso, parece uma tentação para um funcionário insatisfeito. Eu acho que é uma meta razoável que não haja senhas de texto não criptografado em um sistema, em qualquer lugar.

— Barry Shein #

Talvez sim, mas a proposta que você fez é muito pior, pois permite que qualquer usuário local finja trivialmente ser root.

— Michael Hampton

Não, minha proposta era que eles já tivessem que ser raiz unix no servidor local; nesse caso, o mysqld local confia no mysql ou mysqldump etc (cliente) sendo executado como raiz unix e permite que eles procedam como se tivessem se autenticado como raiz mysql . Como eu disse, se eles já são locais raiz unix no servidor, eles podem ignorar a senha root mysql de qualquer maneira com alguns comandos bem documentados ("recuperação da senha root mysql").

— Barry Shein