Przywracanie licencji MySQL dla mysqldump podczas zadania cron PHP: Użyj konta administratora MySQL lub utwórz unikalnego użytkownika? Bezpieczeństwo?

Question

Używam zadania cron, które wykonuje mysqldump za pośrednictwem skryptu PHP, zrzut wymaga przywileju RELOAD. Używanie konta administratora MySQL nie jest w porządku, ale nie tworzy też użytkownika z uprawnieniami administratora.

Moim głównym zmartwieniem jest aspekt bezpieczeństwa, ładuję atrybuty db (nazwa użytkownika, hasło itp.) W chronionej "własności" klasy, z której korzystam.

Zastanawiam się, które podejście jest bardziej sensowne lub czy istnieje inny sposób osiągnięcia tych samych wyników.

---

Przegląd:
LAMP Serwer: CENTOS 5.8, Apache 2.2.3, MySQL 5.0.95, PHP 5.3.3

Cron zadanie zarys:

1. Zrzuca surowy statystyk dane z dwóch tabel InnoDB w witrynie db, one mają relację klucza obcego.
2. załadować dane do tabel w statystyki dB
3. Pobierz ostatnią wartość autoinkrementacja klucza podstawowego, który był przeniesiona
4. użyć wartości klucza podstawowego w zapytaniu, które usuwa skopiowane dane ze strony internetowej db
5. procesowe przesyłane dane w statystykach db do wypełnienia Raporty tabele
6. Po zakończeniu przetwarzania, usunięcia danych surowej statystyk ze statystykami db

Baza danych witryny internetowej jest skonfigurowana jako wzorzec z rejestracją binarną, a zreplikowany serwer zostanie skonfigurowany po tym, jak dane statystyczne nie będą już przechowywane i przetwarzane w bazie danych witryny (replikowanie bazy danych witryny było bodźcem do przeniesienia statystyk ich własna baza danych).

Wszystkie pliki dostępne podczas zadania cron znajdują się poza katalogiem DocumentRoot.

---

bezwzględne Nitty:
mysqldump przeprowadzone w pierwszym etapie wymaga przywilej przeładować, oto polecenie:

<?php 
$SQL1 = "--no-create-info --routines --triggers --master-data "; 
$SQL1 .= "--single-transaction --quick --add-locks --default-character-set=utf8 "; 
$SQL1 .= "--compress --tables stats_event stats_event_attributes"; 

$OUTPUT_FILENAME = "/var/stats/daily/daily-stats-18.tar.gz"; 

$cmd1 = "/usr/bin/mysqldump -u website_user -pXXXXXX website_db $SQL1 | gzip -9 > $OUTPUT_FILENAME"; 

exec($cmd1); 
?> 

Komunikat o błędzie:

mysqldump: Couldn't execute 'FLUSH TABLES': Access denied; you need the RELOAD privilege for this operation (1227) 

Działa dobrze, jeśli używam poświadczeń administratora mysql.

Answer 1

Zastanawiam się, które podejście ma więcej sensu lub czy istnieje inny sposób osiągnięcia tych samych wyników.

Najważniejsze jest to, że użytkownik, który ma określone uprawnienia, musi uruchomić komendę mysqldump.Choć może wydawać się głupie, aby utworzyć nowego użytkownika po prostu dla tego jednego zadania cron, jest to najbardziej proste i proste podejście, które możesz wziąć, co najmniej daje zewnętrzny wygląd lolsecurity.

Biorąc pod uwagę, że jest to środek tymczasowy, dopóki nie można rozpocząć replikacji, nie robi się tutaj żadnej krzywdy. Wykonanie tego przez replikację jest całkowicie drogą do zrobienia, a pomiar stopgap wydaje się rozsądny.

Ponadto, gdy przychodzi czas na replikację, Twoim przyjacielem jest xtrabackup. Zawiera nazwę dziennika binarnego i informacje o położeniu wraz z migawką, którą wykonuje, co powoduje, że konfigurowanie nowych urządzeń podrzędnych jest brzemieniem breeze.

Answer 2

Po prostu napotkałem ten sam błąd (prawdopodobnie w tej samej witrynie, nad którą pracowałem :)), nawet jeśli działa jako użytkownik root MySQL. Udało mi się ominąć to przez nie określając --skip-add-locks, np. to działało:

/usr/bin/mysqldump -u USERNAME -pPW DATABASE_NAME --skip-lock-tables --single-transaction --flush-logs --hex-blob