Pierwsza próba migracji EC2 MySQL do Amazon RDS nie idzie dobrze - uprawnienia SUPER

Próbowałem przenieść istniejącą bazę danych z MySQL działającego na EC2 do nowej instancji Amazon RDS (eksperyment, aby sprawdzić, czy możemy się poruszać). Jak dotąd nie idzie dobrze. Utknąłem przy początkowym imporcie przed skonfigurowaniem replikacji (instrukcje tutaj ).

Przygotowałem instancję RDS zgodnie z opisem i mogę się z nią połączyć z instancji EC2 przy użyciu mysql. Uruchomiłem polecenie mysqldump jako:

mysqldump --master-data --databases db1 db2 > dump.sql

Następnie próbował przesłać go do RDS za pomocą:

mysql -h RDSHost -P 3306 -u rdsuser --password=rdspassword < dump.sql

Pierwszym problemem był wiersz 22 zrzutu:

CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 106;

Ta linia spowodowała błąd ERROR 1227 (42000) at line 22: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Nie ma problemu, po prostu skomentowałem tę linię i mam nadzieję, że uda się ją naprawić później za pomocą mysql.rds_set_external_master (). Ponowiona przesyłanie i ma bardzo podobny błąd: ERROR 1227 (42000) at line 7844: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Sekcja wokół linii 7844 wygląda następująco:

/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`dev`@`localhost` SQL SECURITY DEFINER */
/*!50001 VIEW `jos_contributor_ids_view` AS select `jos_resource_contributors_view`.`uidNumber` AS `uidNumber` from `jos_resource_contributors_view` union select `jos_wiki_contributors_view`.`uidNumber` AS `uidNumber` from `jos_wiki_contributors_view` */;

Komentując pierwsze 2 wiersze i dodając „UTWÓRZ” do trzeciego, udało mi się przejść obok tego. Ale jest mnóstwo takich sekcji. Czy można to obejść bez całej edycji? Czy mysqldumpmożesz nie produkować niczego, co wymaga uprawnień SUPER?

Wygląda na to, że wiele osób miało podobne problemy, na przykład musiało biec sedz danymi wyjściowymi mysqldump / mysqlbinlog! Zamierzam także pisać na forum AWS - naprawdę uważam, że RDS powinien mieć bardziej tolerancyjny sposób importowania z mysqldump, lub konkretnego narzędzia, które można uruchomić na istniejącej bazie danych, aby utworzyć zrzut, który jest skargą na bezpieczeństwo RDS. Zastanawiałem się tylko, czy ktoś ma jakieś inne przepisy lub sztuczki, które mogą tu pomóc.

Dzięki,

Dave

Prawdopodobnie potrzebujesz log_bin_trust_function_creators= 1 na RDS, ale tutaj nie o to chodzi.

Możesz określić  DEFINER wartość inną niż własne konto tylko wtedy, gdy masz  SUPER uprawnienia.

^{- http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html}

Gdy uruchomiony jest zapisany program (proc, funkcja, zdarzenie lub wyzwalacz), wszystko, co robi, ma uprawnienia użytkownika, który go zdefiniował, lub użytkownika wyraźnie podanego w DEFINERdeklaracji. Pozwala to między innymi na przechowywanie programów w celu umożliwienia innym użytkownikom robienia rzeczy na danych, których bezpośrednio nie mają uprawnień do manipulowania, o ile mają oni uprawnienia do korzystania z samego zapisanego programu.

Byłoby to poważną luką w zabezpieczeniach, gdyby osoba niebędąca SUPERużytkownikiem mogła utworzyć procedurę z arbitralnym podmiotem definiującym, ponieważ użytkownik mógłby dowolnie zwiększać swoje uprawnienia.

Dotyczy to również widoków, gdy używany jest kontekst zabezpieczeń definiującego, jak w opublikowanym przykładzie.

Jedną z największych skarg, jakie mam z RDS, jest to, że nie możesz mieć SUPER... a teraz może to być również twoja :) ponieważ ten fakt jest przyczyną twojego problemu.

Oczywiście, gdybym uruchomił zarządzaną usługę MySQL, nikomu też nie dałbym SUPER, więc ich model bezpieczeństwa ma sens, nawet jeśli czasem jest niewygodny.

Jeśli wszystkie obiekty mają tę samą definicję, obejściem może być przywrócenie zrzutu przy użyciu tego konta zamiast konta, którego używasz teraz, ale wydaje się to mało prawdopodobne.

Usunięcie tylko wiersza z DEFINERdeklaracją powinno sprawić, że plik zrzutu zadziała w przypadkach, gdy pojawia się on sam w wierszu lub możesz użyć sed lub perl do zmodyfikowania pliku ... pomysł, o którym już wiem, że go nie lubisz, ale naprawdę fajną rzeczą w MySQL jest to, że takie hackery są całkiem uzasadnione i wcale nie są tak dalekie od tego, co muszę robić jako DBA, nawet w środowisku innym niż RDS.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

... być może nie jest to odpowiedź, na którą liczyłeś, ale możesz ją uruchomić na swoim pliku zrzutu i powinieneś otrzymać nieco bardziej użyteczny plik.

W moim przypadku w zrzucie był wiersz „CHANGE MASTER TO MASTER_LOG_FILE = ...”, który dawał mi błąd. Ten wiersz został dodany przez opcję „--master-data” programu mysqldump. W Amazon AWS musisz rozpocząć replikację, ustawiając dane podstawowe za pomocą procedury „mysql.rds_set_external_master”, zamiast tego czytaj tutaj

Więc po prostu zapisałem notatki z wiersza „head 22 backup.dump”, w którym wiersz 22 zgłosił błąd. Następnie usuń go przed importem, dla mojego dużego pliku używam: „sed '22d' backup.dump> backup_clean.dump”