root @ localhostにはどのような権限を与える必要があります：ALLまたはSuper？ AllおよびSuperの権利も含まれますか？
完全な権限を持つユーザーが必要です。 このユーザーがローカルホストからのみアクセスできる場合、より適切です。 すべての権利にはスーパー権利が含まれます。
動的IPアドレスを受信するラップトップから接続するユーザーがいるため、これらのユーザーを管理する最も簡単な方法は、サーバー名を介してアクセスを提供することです。 IPアドレスではなくホスト名を使用してMySQLデータベースへのアクセスを許可することは可能ですか？ たとえば、「myname@10.10.10.10」ではなくmyname@mymachine.mydomain.com？ これには、ホストキャッシュ/ performance_schemaが必要ですか？
はい、できます。 しかし、ホストキャッシュが何であるかを十分に明らかにしていないようです。 これは常に使用可能な内部構造であり、DNSサーバーからの応答が含まれています。 オンまたはオフにすることはできません。 バージョン5.6より前では、制御することもできませんでした。 たとえば、キャッシュが破損した場合、できることはサーバーを再起動することだけでした。 バージョン5.6では、HOST_CACHEテーブルがパフォーマンススキーマに導入されました。 このテーブルを使用して、ホストキャッシュの内容を確認し、必要に応じてクリアできます。
接続されているユーザーに対応するユーザーテーブルに複数のエントリがある場合（テンプレート、ホスト名、IPなどを使用）、MySQLはどのルールを使用して認証に使用するかを選択しますか？ パスワードが一致するまで、彼はそれぞれをチェックしますか？
いいえ、mysqldはパスワードを解読しようとはしていません。 代わりに、スライド37（p。110）に示すように、ユーザーテーブルを名前とホストで降順に並べ替えます。 その後、彼は最初の適切な行を取ります。 つまり、ユーザーfoo @ somehost、foo @ some％およびfoo@1.2.3.4を作成し、somehostからfooとして接続した場合、mysqldは最初にユーザー名をチェックし、次に最初の適切な行foo @ somehostを選択します。 代わりにsomeotherhostからfooとして接続する場合、mysqldはfoo @ some％を選択します。 IPベースのホストは、mysqldがskip-networkingオプションで起動された場合、または1.2.3.4が「some」で始まっていない名前のホストを指している場合に選択されます。
IPベースのホストと名前ベースのホストを混在させることは、同じホストをsomehostまたは1.2.3.4として受け入れることができる状況では危険です。 この場合、ホストキャッシュまたはDNSサーバーに問題が発生すると、ユーザーテーブルから間違ったエントリが選択される可能性があります。 最初に3つのホスト、uniquehost（1.2.3.4に変換）、somehost（4.3.2.1に変換）、someothershost（4.3.2.2に変換）があったとします。 ここで、uniquehostをIP 1.2.3.5のマシンに移動し、someyetanotherhostという名前のホストにIP 1.2.3.4を使用することにしました。 この場合、IP 1.2.3.4のマシンからのクライアントはfoo @ some％と見なされ、これはあなたが望んでいたものではありません。
このケースを示すために、2人のユーザーを作成し、2つの異なる権利セットを付与しました。
mysql> create user sveta@Thinkie; Query OK, 0 rows affected (0,01 sec) mysql> create user sveta@'192.168.0.4'; Query OK, 0 rows affected (0,00 sec) mysql> grant all on *.* to 'sveta'@'Thinkie'; Query OK, 0 rows affected (0,00 sec) mysql> grant all on db1.* to 'sveta'@'192.168.0.4'; Query OK, 0 rows affected (0,00 sec)
次に、/ etc / hostsファイルを変更し、Thinkieという名前にアドレス192.168.0.4を指定しました。
127.0.0.1 localhost # 127.0.1.1 Thinkie 192.168.0.4 Thinkie
svetaとして接続すると、Thinkieと192.168.0.4の両方が同じホストに変換されます。
sveta@Thinkie:$ mysql -hThinkie -usveta ... mysql> select user(), current_user(); +---------------+----------------+ | user() | current_user() | +---------------+----------------+ | sveta@Thinkie | sveta@thinkie | +---------------+----------------+ 1 row in set (0,00 sec) mysql> show grants; +--------------------------------------------------+ | Grants for sveta@thinkie | +--------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'sveta'@'thinkie' | +--------------------------------------------------+ 1 row in set (0,00 sec) mysql> q Bye sveta@Thinkie:$ mysql -h192.168.0.4 -usveta ... mysql> show grants; +--------------------------------------------------+ | Grants for sveta@thinkie | +--------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'sveta'@'thinkie' | +--------------------------------------------------+ 1 row in set (0,00 sec) mysql> select user(), current_user(); +---------------+----------------+ | user() | current_user() | +---------------+----------------+ | sveta@Thinkie | sveta@thinkie | +---------------+----------------+ 1 row in set (0,00 sec) mysql> q Bye
その後、/ etc / hostsファイルを変更し、Thinkieを127.0.0.1（localhost）に再度バインドしました。
127.0.0.1 localhost 127.0.1.1 Thinkie # 192.168.0.4 Thinkie
ただし、ホスト192.168.0.4は引き続きThinkieに変換しています。
sveta@Thinkie:$ mysql -h192.168.0.4 -usveta ... mysql> select user(), current_user(); +---------------+----------------+ | user() | current_user() | +---------------+----------------+ | sveta@Thinkie | sveta@thinkie | +---------------+----------------+ 1 row in set (0,00 sec) mysql> show grants; +--------------------------------------------------+ | Grants for sveta@thinkie | +--------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'sveta'@'thinkie' | +--------------------------------------------------+ 1 row in set (0,00 sec) mysql> q Bye
この理由は、パフォーマンススキーマで明らかに見られる古いホストキャッシュです。
sveta@Thinkie:$ mysql -uroot ... mysql> select * from performance_schema.host_cacheG *************************** 1. row *************************** IP: 192.168.0.4 HOST: Thinkie HOST_VALIDATED: YES SUM_CONNECT_ERRORS: 0 COUNT_HOST_BLOCKED_ERRORS: 0 COUNT_NAMEINFO_TRANSIENT_ERRORS: 0 COUNT_NAMEINFO_PERMANENT_ERRORS: 0 COUNT_FORMAT_ERRORS: 0 COUNT_ADDRINFO_TRANSIENT_ERRORS: 0 COUNT_ADDRINFO_PERMANENT_ERRORS: 0 COUNT_FCRDNS_ERRORS: 0 COUNT_HOST_ACL_ERRORS: 0 COUNT_NO_AUTH_PLUGIN_ERRORS: 0 COUNT_AUTH_PLUGIN_ERRORS: 0 COUNT_HANDSHAKE_ERRORS: 0 COUNT_PROXY_USER_ERRORS: 0 COUNT_PROXY_USER_ACL_ERRORS: 0 COUNT_AUTHENTICATION_ERRORS: 0 COUNT_SSL_ERRORS: 0 COUNT_MAX_USER_CONNECTIONS_ERRORS: 0 COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0 COUNT_DEFAULT_DATABASE_ERRORS: 0 COUNT_INIT_CONNECT_ERRORS: 0 COUNT_LOCAL_ERRORS: 0 COUNT_UNKNOWN_ERRORS: 0 FIRST_SEEN: 2017-03-02 23:19:32 LAST_SEEN: 2017-03-02 23:20:31 FIRST_ERROR_SEEN: NULL LAST_ERROR_SEEN: NULL 1 row in set (0,00 sec) mysql> truncate performance_schema.host_cache; Query OK, 0 rows affected (0,00 sec) mysql> q Bye
host_cacheテーブルをクリアした後、数値ホストは予想どおりに変換されます。
sveta@Thinkie:$ mysql -h192.168.0.4 -usveta ... mysql> show grants; +----------------------------------------------------------+ | Grants for sveta@192.168.0.4 | +----------------------------------------------------------+ | GRANT USAGE ON *.* TO 'sveta'@'192.168.0.4' | | GRANT ALL PRIVILEGES ON `db1`.* TO 'sveta'@'192.168.0.4' | +----------------------------------------------------------+ 2 rows in set (0,00 sec) mysql> select user(), current_user(); +-------------------+-------------------+ | user() | current_user() | +-------------------+-------------------+ | sveta@192.168.0.4 | sveta@192.168.0.4 | +-------------------+-------------------+ 1 row in set (0,00 sec) mysql> q Bye
非rootユーザーおよび非スーパーユーザーがmysqldumpを使用してデータベースをリセットし、別のサーバーに復元するには、どのような権限が必要ですか？
通常、リセットしようとしているすべてのオブジェクトに対するSELECT特権が必要です。 ビューをリセットする場合、SHOW CREATE TABLEを実行するにはSHOW VIEW特権も必要です。 ストアドプロシージャ/イベントをリセットする場合は、それらにもアクセスする必要があります。 --lock-tablesまたは--lock-all-tablesオプションを使用する場合、LOCKパーミッションが必要です。
MySQLでmax_connectionに到達した場合、すべての特権を持つroot @ localhostまたはスーパー特権を持つユーザーにログインできますか？
ALLにはSUPERが含まれているため、すべての権限を持つユーザーがログインできます。 ただし、このような接続は1つしか存在できないため、アプリケーションユーザーにSUPERまたはALL権限を付与しないでください。
下位レベルで特権を削除できますか？ つまり、データベースレベルでの選択と削除を許可しますが、特定のテーブルの削除は拒否しますか？ または、特権のみを追加できますか？
いいえ、MySQLはそのようなリクエストを拒否します。
mysql> show grants for sveta@'192.168.0.4'; +----------------------------------------------------------+ | Grants for sveta@192.168.0.4 | +----------------------------------------------------------+ | GRANT USAGE ON *.* TO 'sveta'@'192.168.0.4' | | GRANT ALL PRIVILEGES ON `db1`.* TO 'sveta'@'192.168.0.4' | +----------------------------------------------------------+ 2 rows in set (0,00 sec) mysql> revoke update on db1.t1 from sveta@'192.168.0.4'; ERROR 1147 (42000): There is no such grant defined for user 'sveta' on host '192.168.0.4' on table 't1'
特定のロールの付与グループとしてユーザーロールを整理するにはどうすればよいですか？
いくつかのオプションがあります：
- MariaDB 10.0.5以降を使用します。 MariaDBロールのサポートについては、 こちらをご覧ください 。
- MySQL 8.0を使用します。 MySQL 8.0のロールについては、 こちらをご覧ください 。
- MySQL 5.7の使用：スライド19で示したようにロールをシミュレートします（p。53-60）。
- MySQL 5.5および5.6の使用：スライドと同じ方法を使用しますが、プロキシユーザーをサポートするカスタム認証プラグインを使用します。
- 常に：権限を持つテンプレートを作成し、各ユーザーに手動で権限を割り当てます。
プロキシを使用したロールモデリングをMySQL 8.xの実際のロールにどのように移行しますか？
プロキシユーザーを削除して同じ権限を持つロールを作成し、PROXYではなくプロキシユーザーに新しいロールを割り当てます。
Active DirectoryとMySQLを統合してActive Directoryグループを使用するためのプラグインはありますか？
バージョン5.5以降で利用可能な商用のWindows認証プラグインプラグインがあります。 また、オープンソース認証プラグインPercona PAM認証プラグインを使用して、LDAPと同じ方法でActive Directoryに接続することもできます。 これを行う方法を説明する記事がありますが、私自身はこの方法を使用したことがありません。
MySQLで集中認証を使用できますか？
はい、PAMプラグインを使用します。 LDAPおよびActive Directoryの手順があります。 同様の方法を使用して、Kerberosなどの他のタイプの認証をインストールできます。
友人、MySQLでの作業が毎日の仕事である場合は、 PG Day'17 Russiaに来てください。 Sveta Smirnova 、 Petr Zaitsev 、およびその他のPerconaの専門家は、オープンソースデータベースに特化したセクションの一部として、MySQLの構造と機能に関するエキサイティングなレポートとワークショップを準備しています。