Esecuzione di mysql dump in un processo cron senza esporre le password


11

voglio correre

mysqldump -u aUser -p P4SSw0rd --all-databases > backup.sql

in un lavoro cron. Come posso farlo in modo sicuro?

So che potrei mettere il comando proprio lì, ma chiunque abbia accesso alla macchina lo vedrebbe immediatamente tramite crontab. C'è un modo migliore per farlo?


1
Il tuo esempio non è corretto, dovrebbe essere -pP4SSw0rd senza spazio.
Simon Woodside,

Risposte:


14

Come indicato in man mysqldump: vedi 6.1.2.1. Linee guida per l'utente finale per la sicurezza delle password nel manuale di riferimento di MySQL.

Un file di opzioni è la scommessa più sicura, non ultimo secondo il riferimento sopra. Darlo in testo semplice in crontab non è buono, anche perché la riga di comando del processo per impostazione predefinita è visibile psagli altri utenti. Lo stesso vale per le variabili d'ambiente come spiegato nel riferimento.

Parte pertinente del manuale di riferimento di MySQL:

Memorizza la tua password in un file di opzioni. Ad esempio, su Unix, puoi elencare la tua password nella [client]sezione del .my.cnffile nella tua home directory:

[client]
password=your_pass

Per mantenere la password sicura, il file non dovrebbe essere accessibile a nessuno tranne a te stesso. Per garantire ciò, impostare la modalità di accesso ai file su 400o 600. Per esempio:

shell> chmod 600 .my.cnf

Per denominare dalla riga di comando un file di opzioni specifico contenente la password, utilizzare l' --defaults-file=file_nameopzione, dove file_nameè il nome completo del percorso del file. Per esempio:

shell> mysql --defaults-file=/home/francis/mysql-opts

La Sezione 4.2.3.3, "Utilizzo dei file delle opzioni" , tratta i file delle opzioni in modo più dettagliato.

Vedi anche /programming//q/10725209 .


Sembra che il comando ps offuschi la password con un x: ps: mysqldump -uroot -px xx mydb. Non sto dicendo che sia una buona protezione (se si digitano lavori, la password viene rivelata in testo semplice).
ling

4

Esegui il cronjob come utente specifico e usa una semplice logica di Bash per estrarre la password da un file di testo normale archiviato da qualche parte sul sistema con autorizzazioni che consentono solo all'utente (o forse al gruppo) di accedervi.

PASS=`cat /path/to/pwdfile`

 mysqldump -u aUser -p $PASS--all-databases > backup.sql

Quindi, se il cronjob viene eseguito come "esempio" dell'utente, la proprietà del file dovrebbe essere "esempio: esempio" e autorizzata 0400.

Puoi anche ottenere una funzione simile usando un .my.cnf a livello di utente .


1
read PASS < /path/to/pwdfileè un idiomaticamente più pulito per fare la stessa cosa (probabilmente suppongo; si applica superuser.com/q/323060/49184 ).
Daniel Andersson,

* "è UN MODO idiomaticamente più pulito" ... Perso nella modifica.
Daniel Andersson,

Qualcuno con persino la più elementare comprensione di Bash dovrebbe essere in grado di vedere cosa sta succedendo con quel gatto. :)
Garrett,

1
È vero, direi anche che è il modo più comune per farlo, ma è ancora un po 'doloroso :-). Se uno fa di UUOC un'abitudine che morderà quando il file è più grande di ARGMAX, richiede un processo extra invece di usare una shell integrata, potrebbe tentare costrutti come for i in `cat file`; do ...con il suo array di problemi, ecc. Ma ovviamente, come con la maggior parte delle cose: se si sa cosa sta succedendo, si è liberi di fare come si sceglie. Non sono su una crociata qui, indipendentemente da come potrebbe apparire MrGreen.
Daniel Andersson,

0

Chiunque abbia accesso alla macchina ha lo stesso livello di accesso consentito /var/spool/cron/crontabs/a /var/lib/mysqlte. Quindi, impostare le autorizzazioni appropriate per le directory e il gioco è fatto. Chiunque abbia accesso root ha accesso diretto ai file del database direttamente. Chiunque non ti fidi di avere accesso alla macchina non dovrebbe avere affatto accesso alla macchina.

Di solito la gente vede solo i propri cronjob via crontab -l.


0

Ai fini del backup, considera di avere un utente di sola lettura in mysql, in questo modo

CREATE USER bUser IDENTIFIED BY 'p4ss';

GRANT SELECT ON *.* TO bUser@localhost;
GRANT LOCK TABLES ON *.* TO bUser@localhost;

mysqldump richiede solo SELECTe LOCK TABLESprivilegi per fare il suo lavoro.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.