web-dev-qa-db-ja.com

EC2 MySQLをAmazon RDSに移行する最初の試みはうまくいきません-スーパー特権

EC2で実行されているMySQLから既存のデータベースを新しいAmazon RDSインスタンスに移動しようとしています(移動できるかどうかを確認するための実験)。これまでのところ、うまくいっていません。レプリケーションをセットアップする前の最初のインポートで立ち往生しています(指示 ここ )。

説明したようにRDSインスタンスを準備し、mysqlを使用してEC2インスタンスからそれに接続できます。私はmysqldumpコマンドを次のように実行しました。

_mysqldump --master-data --databases db1 db2 > dump.sql_

次に、それをRDSにアップロードしようとしました:

_mysql -h RDSHost -P 3306 -u rdsuser --password=rdspassword < dump.sql_

最初の問題は、ダンプの22行目にありました。

マスターをMASTER_LOG_FILE = 'mysql-bin.000002'、MASTER_LOG_POS = 106に変更します。

この行により、エラーERROR 1227 (42000) at line 22: Access denied; you need (at least one of) the SUPER privilege(s) for this operationが発生しました。問題ありません。その行をコメント化し、後でmysql.rds_set_external_master()を介して修正したいと考えています。アップロードを再試行すると、非常によく似たエラーが発生しました:ERROR 1227 (42000) at line 7844: Access denied; you need (at least one of) the SUPER privilege(s) for this operation。 7844行目のセクションは次のようになります。

_/*!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` */;
_

最初の2行をコメントアウトし、3番目の行に「CREATE」を追加することで、これを回避することができました。しかし、このようなセクションのトンがあります。すべての編集なしでこれを回避する方法はありますか? SUPER特権を必要とするものを生成しないmysqldumpのオプションのように?

Mysqldump/mysqlbinlogの出力に対してsedを実行する必要があるなど、多くの人が同様の問題を抱えているようです!私もAWSフォーラムに投稿します-実際には、RDSにはmysqldumpからインポートするより寛容な方法、または既存のデータベースに対して実行してRDSセキュリティに不満のあるダンプを作成できる特定のツールが必要だと思います。誰かがここで役立つかもしれない他のレシピやトリックを持っているかどうか疑問に思いました。

おかげで、

デイブ

11
dsl101

おそらく必要ですlog_bin_trust_function_creators = RDSでは1ですが、ここでは問題ではありません。

DEFINER特権がある場合にのみ、自分のアカウント以外のSUPER値を指定できます。

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

ストアドプログラム(proc、function、event、またはtrigger)が実行されている場合、それを実行するすべてのものは、それを定義したユーザー、またはDEFINER宣言で明示的に宣言されたユーザーの権限を持っています。これにより、特に、ストアドプログラム自体が使用する権限を持っている限り、他のユーザーが直接操作する権限のないデータに対して他のユーザーがデータを操作できるようになります。

これは深刻な脆弱性であり、SUPER以外のユーザーが任意の定義者を使用してプロシージャを作成できる場合、ユーザーは自分の特権を自由にエスカレートできるためです。

もちろんこれは、投稿した例のように、定義者のセキュリティコンテキストが使用される場合のビューにも当てはまります。

私がRDSに関して抱えている最大の不満の1つは、あなたがSUPER...を持つことができないことです。そして今、それもあなたの1つである可能性があります:)その事実はあなたが抱えている問題の原因です。

もちろん、マネージドMySQLサービスを実行している場合は、誰にもSUPERを与えないので、扱いにくい場合でも、セキュリティモデルは理にかなっています。

すべてのオブジェクトに同じ定義者がいる場合、回避策は、現在使用しているアカウントではなく、そのアカウントを使用してダンプを復元することですが、そうではないようです。

DEFINER宣言を含む行のみを削除すると、それ自体が行に表示される場合にダンプファイルが機能するはずです。または、sedまたはPerlを使用してファイルを変更することもできます...好きではありませんが、このようなハッカーが非常に合法であるのはMySQLの素晴らしい点であり、RDS以外の環境でDBAとして実行しなければならないことからそれほど遠くはありません。

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

...おそらくあなたが望んだ答えではないかもしれませんが、あなたはそれをダンプファイルに対して実行することができ、少し使いやすいファイルになるはずです。

26

私の場合、エラーを引き起こしていたダンプの "CHANGE MASTER TO MASTER_LOG_FILE = ..."行でした。この行は、mysqldumpの「--master-data」オプションによって追加されました。 Amazon AWSでは、 "mysql.rds_set_external_master"プロシージャを使用してマスターの詳細を設定することでレプリケーションを開始する必要があります。代わりに here を読んでください

そのため、22行目でエラーが報告された "head 22 backup.dump"という行のメモを書きました。次に、インポートする前にそれを削除します。私が使用する大きなファイルの場合:「sed '22d' backup.dump> backup_clean.dump」

1
Igor Toma