Używanie mysqldump w zadaniu cron bez hasła roota

14

Jeśli zaloguję się przy użyciu hasła roota na swoim polu, mogę po prostu wpisać

mysqldump - wszystkie bazy danych, a ja otrzymam oczekiwany „zrzut”.

Konfiguruję zadanie w cron.daily, aby uruchomić i zrzucić je na dysk zapasowy. Problemem jest to, że chociaż użytkownik działa jako root, pojawia się następujący komunikat

mysqldump: Wystąpił błąd: 1045: Odmowa dostępu dla użytkownika „root” @ „localhost” (przy użyciu hasła: NIE)

podczas próby połączenia. I nie chcą ciężko kodem hasło użytkownika root bazy mysql w skrypcie (kto).

Biorąc pod uwagę, że mogę po prostu wpisać „mysqldump” w wierszu poleceń w mojej powłoce bash, musi być jakoś obejść za pomocą parametru -u. Mam już #! / Bin / bash na górze skryptu.

Czego tu brakuje, żeby nie pytać o hasło roota do bazy danych?

mysql scripting cron

— Oprogramowanie Mech
źródło

12

Aby połączyć się z serwerem mysql, musisz podać poświadczenia. Możesz określić je w pliku konfiguracyjnym, przekazać je za pomocą wiersza polecenia lub po prostu utworzyć konto, które nie wymaga poświadczeń.

Oczywiście nigdy nie należy używać opcji bez hasła, linia poleceń przejścia nie jest świetna, ponieważ każdy, kto potrafi uruchomić ps, może zobaczyć linię poleceń.

Zalecaną opcją jest utworzenie pliku konfiguracyjnego mysql z poświadczeniami w nim zawartymi, a następnie ochrona tego pliku za pomocą uprawnień systemu plików, aby tylko użytkownik kopii zapasowej mógł uzyskać do niego dostęp.

Możesz zalogować się do serwera mysql podczas logowania interaktywnego, ponieważ root wydaje się sugerować, że albo nie masz ustawionego hasła roota, albo masz plik konfiguracyjny, którego skrypt nie znajduje. Jeśli masz plik .my.cnf, może być konieczne ręczne wskazanie go. Jeśli twoje konto root nie ma ustawionego hasła, zdecydowanie zachęcam do naprawy tego.

Aktualizacja (2016-06-29) Jeśli korzystasz z mysql 5.6.6 lub nowszego, powinieneś spojrzeć na narzędzie mysql_config_editor , które umożliwia przechowywanie poświadczeń w zaszyfrowanym pliku. Dzięki Giovanni za to, że mi o tym wspomniał.

— Zoredache
źródło

1

Ta metoda nadal wymaga niezaszyfrowanego hasła w postaci zwykłego tekstu, aby być w systemie. Właśnie tego staram się uniknąć.

— Mech Software,

> albo nie masz ustawionego hasła roota, albo masz plik konfiguracyjny, którego skrypt nie znajduje. Autor wyraźnie stwierdza, że istnieje hasło mysql dla użytkownika root i że próbuje uzyskać dostęp do bazy danych bez podawania go komendzie mysqldump: „(używając hasła: NIE)”. Stąd błąd odmowy dostępu.

— monomyth

1

@monomyth, autor stwierdza również, że może logować się bez hasła podczas interaktywnego logowania jako root. To mówi mi, że coś jest nie tak.

— Zoredache

2

@Mech Software, Nie ma sensu próbować chronić się przed kontem root. Jeśli ktoś ma konto root, może po prostu zrestartować mysql i całkowicie ominąć system uprawnień.

— Zoredache

1

Powodem, dla którego mogłem się zalogować, było określenie konta root .my.cnf z 600 uprawnieniami, więc w ten sposób powłoka uzyskiwała dostęp. cron jednak musi ignorować plik, więc użyłem parametru w tym poście, aby go wskazać.

— Mech Software,

3

Bezpieczeństwo nie powinno odbywać się przez zaciemnienie. Jeśli obawiasz się, że ktoś ma dostęp do twojego konta root, nie ma znaczenia, czy hasło roota mysql jest przechowywane w skrypcie, ponieważ wszystkie twoje dane są dostępne w zrzutach mysql lub plikach bazy danych. Tak więc prawdziwe pytanie brzmi: co próbujesz chronić?

Jeśli nie chcesz, aby inni uzyskiwali hasło, które pozwoli im zmieniać dane w bazie danych, musisz utworzyć użytkownika z odpowiednimi uprawnieniami .

Jeśli nie chcesz, aby hasło mysql było widoczne dla dowolnego konta lokalnego, z wyjątkiem uprawnień pliku root ustawionych w tym skrypcie na 0700 i właściciela root.

— monomyth
źródło

1

Wydaje mi się, że nadal nie rozumiem, że jeśli mogę napisać (z poziomu root) mysqldump bez wprowadzania hasła, dlaczego nie mogę uruchomić go przez zadanie cron w ten sam sposób. Brakuje elementu wymagającego parametru -p. Nie próbuję „zasłaniać” hasła, wolałbym go nigdy nie wprowadzać. Coś szczególnego dla samego loginu root pozwala na dostęp, więc dlaczego nie można tego zreplikować za pomocą crona?

— Mech Software,

Jeśli zauważysz, że możesz zalogować się bez hasła i przy użyciu hasła tego samego użytkownika „root”, możliwe, że w bazie danych mysql jest wielu użytkowników root. Niektóre z nich mogą nie mieć ustawionego hasła. Możesz usunąć hasło z „root” @ „localhost”, ale wtedy nie tylko cron będzie mógł połączyć się z twoją bazą danych, ale każdy z lokalnym kontem. Nie różni się to (lub gorzej) od posiadania hasła w czystym tekście.

— monomyth

Myślę, że chodzi o to, że MechSoftware robi to, że rootowanie zasadniczo daje ci dostęp do odczytu plików bazy danych i nie są one szyfrowane. Dlatego wymaganie hasła root MySQL od użytkownika root tylko do wydrukowania danych, do których zasadniczo już mają dostęp, to „bezpieczeństwo poprzez zaciemnienie”. Poza tym bardzo łatwo jest zepsuć uprawnienia, np. Jeśli ktoś ustawia je rekurencyjnie dla katalogu, jeśli istnieje dowiązanie symboliczne do pliku itp.

— Wrzesień

2

Twoje użycie powłoki może to zrobić, ponieważ masz powłokę, z której można ją uruchomić, tj. Po zalogowaniu się uruchamiane są wszystkie skrypty powłoki w profilu.

Cron nie ma takich luksusów. Kiedy się zaloguje (jako root), zaloguje się przy użyciu domyślnej powłoki. Zapobiega to zdalnemu logowaniu się, ale oznacza również, że nie są uruchamiane skrypty automatycznego logowania.

Możesz ustawić powłokę, pod którą będzie działał cron, edytować crontab i dodać zmienne SHELL i HOME, np.

SHELL=/bin/bash
HOME=/root

jeśli nie są ustawione, cron będzie działał z powłoką i katalogiem domowym określonym w / etc / passwd (które prawdopodobnie są niczym, prawdopodobnie / bin / sh).

Jeśli chcesz zobaczyć, jak środowisko cron działa, dodaj zadanie cron, które eksportuje env do pliku, np .:

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

— gbjbaanb
źródło

1

Jeśli skrypt jest uruchamiany przez root, możesz utworzyć plik /root/.my.cnf z uprawnieniami 600 i następującą zawartością:

[client]
user = DBUSERNAME
password = DBPASSWORD

(gdzie oczywiście podajesz nazwę użytkownika MySQL i hasło).

Plik ten zostanie automatycznie odczytany przez dowolne narzędzie wiersza polecenia mysql, jeśli zostanie uruchomione jako root. Nie musisz już podawać go w wierszu poleceń. 600 uprawnień chroni go przed wścibskimi oczami.

— Martijn Heemels
źródło

1

Odkryłem, że tak było w przypadku, w jaki sposób mogłem nam zrobić mysqldump bez hasła. To rozwiązało tajemnicę, w jaki sposób robi to MUSZLI, więc dlaczego cron go nie czyta?

— Mech Software,

1

mysqldump po uruchomieniu z crona może nie być w stanie zlokalizować pliku .my.cnf. Rozwiązaniem jest dodanie parametru mysqldump, aby jawnie odczytać opcje w pliku.my.cnf, tj. --Defaults-extra-file = / root / .my.cnf Nauczyłem się tego z dwóch innych odpowiedzi na temat przepełnienia stosu. Zobacz stackoverflow.com/a/602054/854680 i stackoverflow.com/a/890554/854680

— MikeOnline

1

Debiut może być bardzo frustrujący. Kiedy zadania crona są wykonywane, nie mają ustawionego środowiska takiego, jak w przypadku powłoki.

Wskazówki dla crona:

używaj pełnych ścieżek do wszystkiego - „ECHO = / bin / echo” itp .: (zdefiniuj zmienne u góry, aby ułatwić)
ustaw MAILTO, aby otrzymywać e-maile z każdego zadania (lub zlecenia przekierowują stderr / stdout do pliku)

Jeśli użytkownik root może to zrobić z poziomu powłoki, cron powinien mieć taką możliwość. Upewnij się, że jawnie określono plik konfiguracyjny do użycia w wierszu polecenia.

0

Chociaż kilka z tych odpowiedzi jest pomocnych, kilka jest mylących, ponieważ użytkownik root w systemie Unix i użytkownik root w mysql nie są tacy sami i w zasadzie nie mają żadnych relacji innych niż obaj używają nazwy logowania „root”. Może to oczywiste, ale wydaje się, że niektóre odpowiedzi łączą te dwie kwestie.

Co może być przydatną opcją (może istnieje?) Dla mysqld, byłoby zezwolenie programom klienckim takim jak mysql lub mysqldump itp. Działającym jako root systemu UNIX na dostęp do root @ localhost mysqld bez hasła bez konieczności przechowywania hasła root @ localhost (mysql) w pliku my.cnf lub podobnym.

Wiem, że to trochę denerwuje, ale powodem jest to, że każdy, kto działa jako lokalny (na serwerze mysqld) root root w unixie, może i tak ominąć zabezpieczenia mysqld. A posiadanie my.cnf z hasłem root mysqld 7x24 lub nawet tworzenie / usuwanie my.cnf z hasłem root mysql (skąd to hasło pochodzi?) W locie (np. Aby zrobić mysqldump) denerwuje mnie .

Wymagałoby to pewnej infrastruktury i myślenia, ponieważ trzeba by było zaufać mysql / mysqldump / etc, aby przekazać mysqld, że naprawdę wierzy, że jest on zarządzany przez lokalne konto root Unix.

Ale na przykład ograniczenie tylko do gniazda unix mysqld, bez TCP, może pomóc, przynajmniej jako zdecydowanie zalecana opcja tej opcji. To może ustalić, że klient działa lokalnie, co prawdopodobnie nie wystarcza. Ale to może być początek pomysłu. Być może przesłanie deskryptora pliku przez gniazdo unix może być kolejnym kawałkiem (google, jeśli to brzmi jak szalona rozmowa).

PS Nie. Nie zamierzam tutaj próbować burzy mózgów, jak to wszystko może działać w systemie operacyjnym innym niż Unix, co prawdopodobnie przekłada się na inne systemy operacyjne.

— Barry Shein
źródło

1

Wprowadzenie poświadczeń /root/.my.cnfz odpowiednimi uprawnieniami starannie rozwiązuje problem.

— Michael Hampton

Nie zgadzam się, teraz każdy, kto może uzyskać dostęp do tego pliku, w tym za pośrednictwem innej wady systemu, ma root mysql pw. I jest tam do zaatakowania przez całą dobę, w stałej lokalizacji pliku (co prawda nie musiałoby to być w katalogu / root.) Ale na przykład ktokolwiek uruchamia zrzuty systemu plików lub może uzyskać do niego dostęp, może wyciągnąć go z plik zrzutu systemu plików. W takim przypadku brzmi to jak pokusa dla niezadowolonego pracownika. Myślę, że rozsądnym celem jest, aby żadne hasła w postaci czystego tekstu nie istniały w systemie, nigdzie.

— Barry Shein

Być może tak, ale twoja propozycja jest znacznie gorsza, ponieważ pozwala każdemu lokalnemu użytkownikowi w prosty sposób udawać roota.

— Michael Hampton

Nie, moja propozycja była taka, że muszą już być rootem uniksowym na lokalnym serwerze, w którym to przypadku lokalny mysqld ufa, że mysql lub mysqldump itp. (Klient) działa jako root unix i pozwala im postępować tak, jakby uwierzytelnili się jako root mysql . Jak powiedziałem, jeśli są już lokalni root na serwerze Unix, mogą pominąć hasło roota mysql za pomocą kilku dobrze udokumentowanych poleceń („odzyskiwanie hasła roota mysql”).

— Barry Shein