MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
MySQL アカウントに付与される権限によって、アカウントが実行できる操作が決まります。 MySQL の権限は、適用されるコンテキストと操作のレベルによって異なります:
管理権限によって、ユーザーは MySQL サーバーの動作を管理できます。 これらの権限は特定のデータベースに固有でないため、グローバルです。
データベース権限は、データベースおよびデータベース内のすべてのオブジェクトに適用されます。 これらの権限は、特定のデータベースに付与したり、すべてのデータベースに適用されるようにグローバルに付与したりすることができます。
テーブル、インデックス、ビュー、ストアドルーチンなどのデータベースオブジェクトに対する権限は、データベース内の特定のオブジェクト、データベース内の特定のタイプのすべてのオブジェクト (データベース内のすべてのテーブルなど)、またはすべてのデータベース内の特定のタイプのすべてのオブジェクトに対してグローバルに付与できます。
権限は、静的 (サーバーに組み込まれている) か動的 (実行時に定義される) かによっても異なります。 権限が静的であるか動的であるかは、ユーザーアカウントおよびロールに付与される可用性に影響します。 静的権限と動的権限の違いの詳細は、静的権限と動的権限 を参照してください。)
アカウント権限に関する情報は、mysql
システムデータベースの付与テーブルに格納されます。 これらのテーブルの構造および内容の説明は、セクション6.2.3「付与テーブル」 を参照してください。 MySQL サーバーは、起動時に付与テーブルの内容をメモリーに読み取り、セクション6.2.13「権限変更が有効化される時期」 に示されている状況下でそれらをリロードします。 サーバーは、付与テーブルのメモリー内コピーに基づいてアクセス制御の決定を行います。
一部の MySQL リリースでは、新しい権限または機能を追加するために付与テーブルに変更が導入されています。 新しい機能を確実に利用できるようにするには、MySQL をアップグレードするたびに付与テーブルを現在の構造に更新します。 セクション2.11「MySQL のアップグレード」を参照してください。
次の各セクションでは、使用可能な権限の概要、各権限の詳細な説明および使用上のガイドラインを示します。
次のテーブルに、GRANT
および REVOKE
ステートメントで使用される静的権限名と、付与テーブルの各権限に関連付けられたカラム名および権限が適用されるコンテキストを示します。
表 6.2 GRANT および REVOKE に許可される静的権限
権限 | 付与テーブルカラム | コンテキスト |
---|---|---|
ALL [PRIVILEGES] |
「「すべての権限」」のシノニム | サーバー管理 |
ALTER |
Alter_priv |
テーブル |
ALTER ROUTINE |
Alter_routine_priv |
ストアドルーチン |
CREATE |
Create_priv |
データベース、テーブルまたはインデックス |
CREATE ROLE |
Create_role_priv |
サーバー管理 |
CREATE ROUTINE |
Create_routine_priv |
ストアドルーチン |
CREATE TABLESPACE |
Create_tablespace_priv |
サーバー管理 |
CREATE TEMPORARY TABLES |
Create_tmp_table_priv |
テーブル |
CREATE USER |
Create_user_priv |
サーバー管理 |
CREATE VIEW |
Create_view_priv |
ビュー |
DELETE |
Delete_priv |
テーブル |
DROP |
Drop_priv |
データベース、テーブルまたはビュー |
DROP ROLE |
Drop_role_priv |
サーバー管理 |
EVENT |
Event_priv |
データベース |
EXECUTE |
Execute_priv |
ストアドルーチン |
FILE |
File_priv |
サーバーホストでのファイルアクセス |
GRANT OPTION |
Grant_priv |
データベース、テーブル、またはストアドルーチン |
INDEX |
Index_priv |
テーブル |
INSERT |
Insert_priv |
テーブルまたはカラム |
LOCK TABLES |
Lock_tables_priv |
データベース |
PROCESS |
Process_priv |
サーバー管理 |
PROXY |
proxies_priv テーブルを参照 |
サーバー管理 |
REFERENCES |
References_priv |
データベースまたはテーブル |
RELOAD |
Reload_priv |
サーバー管理 |
REPLICATION CLIENT |
Repl_client_priv |
サーバー管理 |
REPLICATION SLAVE |
Repl_slave_priv |
サーバー管理 |
SELECT |
Select_priv |
テーブルまたはカラム |
SHOW DATABASES |
Show_db_priv |
サーバー管理 |
SHOW VIEW |
Show_view_priv |
ビュー |
SHUTDOWN |
Shutdown_priv |
サーバー管理 |
SUPER |
Super_priv |
サーバー管理 |
TRIGGER |
Trigger_priv |
テーブル |
UPDATE |
Update_priv |
テーブルまたはカラム |
USAGE |
「権限なし」のシノニムです | サーバー管理 |
次のテーブルに、GRANT
および REVOKE
ステートメントで使用される動的権限名と、その権限が適用されるコンテキストを示します。
表 6.3 GRANT および REVOKE に許可される動的権限
権限 | コンテキスト |
---|---|
APPLICATION_PASSWORD_ADMIN |
デュアルパスワード管理 |
AUDIT_ADMIN |
監査ログの管理 |
BACKUP_ADMIN |
バックアップ管理 |
BINLOG_ADMIN |
バックアップとレプリケーションの管理 |
BINLOG_ENCRYPTION_ADMIN |
バックアップとレプリケーションの管理 |
CLONE_ADMIN |
クローン管理 |
CONNECTION_ADMIN |
サーバー管理 |
ENCRYPTION_KEY_ADMIN |
サーバー管理 |
FIREWALL_ADMIN |
ファイアウォール管理 |
FIREWALL_USER |
ファイアウォール管理 |
FLUSH_OPTIMIZER_COSTS |
サーバー管理 |
FLUSH_STATUS |
サーバー管理 |
FLUSH_TABLES |
サーバー管理 |
FLUSH_USER_RESOURCES |
サーバー管理 |
GROUP_REPLICATION_ADMIN |
レプリケーション管理 |
INNODB_REDO_LOG_ARCHIVE |
redo ログアーカイブ管理 |
NDB_STORED_USER |
NDB Cluster |
PERSIST_RO_VARIABLES_ADMIN |
サーバー管理 |
REPLICATION_APPLIER |
レプリケーションチャネル用の PRIVILEGE_CHECKS_USER |
REPLICATION_SLAVE_ADMIN |
レプリケーション管理 |
RESOURCE_GROUP_ADMIN |
リソースグループ管理 |
RESOURCE_GROUP_USER |
リソースグループ管理 |
ROLE_ADMIN |
サーバー管理 |
SESSION_VARIABLES_ADMIN |
サーバー管理 |
SET_USER_ID |
サーバー管理 |
SHOW_ROUTINE |
サーバー管理 |
SYSTEM_USER |
サーバー管理 |
SYSTEM_VARIABLES_ADMIN |
サーバー管理 |
TABLE_ENCRYPTION_ADMIN |
サーバー管理 |
VERSION_TOKEN_ADMIN |
サーバー管理 |
XA_RECOVER_ADMIN |
サーバー管理 |
静的権限は、実行時に定義される動的権限とは対照的に、サーバーに組み込まれます。 次のリストでは、MySQL で使用可能な各静的権限について説明します。
特定の SQL ステートメントには、ここに示されているよりも具体的な権限要件がある場合もあります。 そのような場合、該当するステートメントの説明で詳細を示します。
これらの権限指定子は、「「特定の権限レベルで使用可能なすべての権限」」 (GRANT OPTION
を除く) の短縮形です。 たとえば、グローバルレベルまたはテーブルレベルで ALL
を付与すると、すべてのグローバル権限またはすべてのテーブルレベル権限がそれぞれ付与されます。
ALTER TABLE
ステートメントを使用してテーブルの構造を変更できます。 ALTER TABLE
には CREATE
および INSERT
権限も必要です。 テーブルの名前を変更するには、古いテーブルで ALTER
および DROP
を、新しいテーブルで CREATE
および INSERT
を実行する必要があります。
ストアドルーチン (ストアドプロシージャーおよびストアドファンクション) を変更または削除するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER
として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。
新しいデータベースおよびテーブルを作成するステートメントの使用を有効にします。
CREATE ROLE
ステートメントの使用を有効にします。 (CREATE USER
権限により、CREATE ROLE
ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。
CREATE ROLE
および DROP ROLE
権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER
ほど強力ではありません。 これらは、CREATE USER
でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。
ストアドルーチン (ストアドプロシージャーとストアドファンクション) を作成するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER
として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。
テーブルスペースおよびログファイルグループを作成、変更または削除するステートメントを使用可能にします。
CREATE TEMPORARY TABLE
ステートメントを使用した一時テーブルの作成を有効にします。
セッションが一時テーブルを作成したあと、サーバーはそのテーブルに対するそれ以上の権限チェックを実行しません。 セッションの作成によって、DROP TABLE
、INSERT
、UPDATE
、SELECT
などのあらゆる操作をテーブル上で実行できます。 詳細は、セクション13.1.20.2「CREATE TEMPORARY TABLE ステートメント」を参照してください。
ALTER USER
, CREATE ROLE
, CREATE USER
, DROP ROLE
, DROP USER
, RENAME USER
および REVOKE ALL PRIVILEGES
ステートメントの使用を有効にします。
CREATE VIEW
ステートメントの使用を有効にします。
データベース内のテーブルから行を削除できます。
既存のデータベース、テーブルおよびビューを削除するステートメントを使用可能にします。 パーティションテーブルで ALTER TABLE ... DROP PARTITION
ステートメントを使用するには、DROP
権限が必要です。 DROP
権限は TRUNCATE TABLE
のためにも必要です。
DROP ROLE
ステートメントの使用を有効にします。 (CREATE USER
権限により、DROP ROLE
ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。
CREATE ROLE
および DROP ROLE
権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER
ほど強力ではありません。 これらは、CREATE USER
でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。
イベントスケジューラのイベントを作成、変更、削除、または表示するステートメントの使用を有効にします。
ストアドルーチン (ストアドプロシージャーとストアドファンクション) を実行するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER
として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。
次の操作およびサーバーの動作に影響します:
LOAD DATA
および SELECT ... INTO OUTFILE
ステートメントと LOAD_FILE()
関数を使用して、サーバーホスト上のファイルの読取りおよび書込みを有効にします。 FILE
権限を持つユーザーは、すべてのユーザーから読み取り可能であるか、MySQL サーバーによって読み取り可能なサーバーホスト上のすべてのファイルを読み取ることができます。 (このことは暗黙的に、データベースディレクトリ内のあらゆるファイルにサーバーからアクセスできるため、ユーザーはそれらのすべてのファイルを読み取ることができることを意味します。)
MySQL サーバーが書込みアクセス権を持つ任意のディレクトリに新しいファイルを作成できます。 これは、権限テーブルを実装するファイルを格納するサーバーのデータディレクトリを含みます。
CREATE TABLE
ステートメントに DATA DIRECTORY
または INDEX DIRECTORY
テーブルオプションを使用できるようにします。
セキュリティ対策として、サーバーは既存のファイルを上書きしません。
ファイルの読取りおよび書込みが可能な場所を制限するには、secure_file_priv
システム変数を特定のディレクトリに設定します。 セクション5.1.8「サーバーシステム変数」を参照してください。
自分が所有する権限を他のユーザーに付与したり、他のユーザーから取り消すことができます。
インデックスを作成または削除するステートメントの使用を有効にします。 INDEX
は既存のテーブルに適用されます。 テーブルに対する CREATE
権限を持つ場合、CREATE TABLE
ステートメントにインデックス定義を含めることも可能です。
データベースのテーブルに行を挿入できます。 ANALYZE TABLE
、OPTIMIZE TABLE
、REPAIR TABLE
などのテーブル保守に関するステートメントにも、INSERT
権限が必要です。
明示的な LOCK TABLES
ステートメントを使用して、SELECT
権限を持つテーブルをロックできます。 これには、他のセッションによるロックされたテーブルの読取りを防止する書込みロックの使用が含まれます。
PROCESS
権限は、サーバー内で実行されているスレッドに関する情報 (セッションによって実行されているステートメントに関する情報) へのアクセスを制御します。 SHOW PROCESSLIST
ステートメント、mysqladmin processlist コマンド、INFORMATION_SCHEMA.PROCESSLIST
テーブル、およびパフォーマンススキーマ processlist
テーブルを使用して使用可能なスレッド情報には、次のようにアクセスできます:
PROCESS
権限を持つユーザーは、他のユーザーに属するスレッドも含め、すべてのスレッドに関する情報にアクセスできます。
PROCESS
権限がない場合、非匿名ユーザーは自分のスレッドに関する情報にアクセスできますが、他のユーザーのスレッドにはアクセスできません。また、匿名ユーザーはスレッド情報にアクセスできません。
パフォーマンススキーマ threads
テーブルはスレッド情報も提供しますが、テーブルアクセスは別の特権モデルを使用します。 セクション27.12.19.10「スレッドテーブル」を参照してください。
PROCESS
権限では、SHOW ENGINE
ステートメントの使用、INFORMATION_SCHEMA
InnoDB
テーブル (INNODB_
で始まる名前を持つテーブル) へのアクセスおよび、(MySQL 8.0.21 の時点で) INFORMATION_SCHEMA
FILES
テーブルへのアクセスも可能です。
あるユーザーが別のユーザーになりすましたり、別のユーザーとして知られるようにします。 セクション6.2.18「プロキシユーザー」を参照してください。
外部キー制約を作成するには、親テーブルに対する REFERENCES
権限が必要です。
RELOAD
では、次の操作が可能です:
FLUSH
ステートメントの使用。
FLUSH
操作と同等の mysqladmin コマンドの使用: flush-hosts
, flush-logs
, flush-privileges
, flush-status
, flush-tables
, flush-threads
, refresh
および reload
。
reload
コマンドは、付与テーブルをメモリーにリロードするようにサーバーに指示します。flush-privileges
は reload
のシノニムです。 refresh
コマンドは、ログファイルを閉じて再オープンし、すべてのテーブルをフラッシュします。 ほかの flush-
コマンドは xxx
refresh
に類似した機能を実行しますが、より具体的であるため一部の状況では好ましい場合があります。 たとえば、ログファイルだけをフラッシュするときは、refresh
よりも flush-logs
を選択することをお勧めします。
様々な FLUSH
操作を実行する mysqldump オプションの使用: --flush-logs
および --master-data
。
RESET MASTER
および RESET REPLICA | SLAVE
ステートメントの使用。
SHOW MASTER STATUS
、SHOW REPLICA | SLAVE STATUS
および SHOW BINARY LOGS
ステートメントの使用を有効にします。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。
SHOW REPLICAS | SHOW SLAVE HOSTS
、SHOW RELAYLOG EVENTS
および SHOW BINLOG EVENTS
ステートメントを使用して、レプリケーションソースサーバー上のデータベースに対して行われた更新をアカウントがリクエストできるようにします。 この権限は、mysqlbinlog オプションの --read-from-remote-server
(-R
) および --read-from-remote-master
を使用する場合にも必要です。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。
データベース内のテーブルから行を選択できます。 SELECT
ステートメントには、実際にテーブルにアクセスする場合にのみ SELECT
権限が必要です。 一部の SELECT
ステートメントはテーブルにアクセスしないため、あらゆるデータベースへのアクセス権がなくても実行できます。 たとえば、テーブルを参照しない式を評価するための単純な計算機として SELECT
を使用することができます。
SELECT 1+1; SELECT PI()*2;
SELECT
権限は、カラム値を読み取るほかのステートメントについても必要です。 たとえば、UPDATE
ステートメントの代入 col_name
=expr
の右辺で参照されるカラムや、DELETE
または UPDATE
ステートメントの WHERE
句で指定されるカラムについて、SELECT
が必要です。
EXPLAIN
で使用されるテーブルまたはビュー (ビュー定義の基礎となるテーブルを含む) には、SELECT
権限が必要です。
SHOW DATABASE
ステートメントを発行して、アカウントがデータベース名を表示できるようにします。 この権限を持たないアカウントには、アカウントが一部の権限を持つデータベースしか表示されず、サーバーが --skip-show-database
オプションで起動されている場合はステートメントを一切使用できません。
静的グローバル権限はすべてのデータベースに対する権限とみなされるため、静的グローバル権限を使用すると、ユーザーは、部分的な取消しによってデータベースレベルで制限されているデータベースを除き、SHOW DATABASES
を使用するか、INFORMATION_SCHEMA
の SCHEMATA
テーブルを調べることで、すべてのデータベース名を表示できます。
SHOW CREATE VIEW
ステートメントの使用を有効にします。 この権限は、EXPLAIN
で使用されるビューにも必要です。
SHUTDOWN
および RESTART
ステートメント、mysqladmin shutdown コマンドおよび mysql_shutdown()
C API 関数の使用を有効にします。
SUPER
は強力で遠いリカバリ権限であるため、軽く付与しないでください。 アカウントで SUPER
操作のサブセットのみを実行する必要がある場合は、かわりに 1 つ以上の動的権限を付与することで、必要な権限セットを実現できる場合があり、それぞれがより制限された機能を構成します。 動的権限の説明を参照してください。
SUPER
は非推奨であり、将来のバージョンの MySQL で削除される予定です。 SUPER から動的権限へのアカウントの移行を参照してください。
SUPER
は、次の操作およびサーバーの動作に影響します:
実行時のシステム変数の変更を有効にします:
SET GLOBAL
および SET PERSIST
を使用して、グローバルシステム変数に対するサーバー構成の変更を有効にします。
対応する動的権限は SYSTEM_VARIABLES_ADMIN
です。
特別な権限を必要とする制限付きセッションシステム変数の設定を有効にします。
対応する動的権限は SESSION_VARIABLES_ADMIN
です。
セクション5.1.9.1「システム変数権限」も参照してください。
グローバルトランザクション特性の変更を有効にします (セクション13.3.7「SET TRANSACTION ステートメント」 を参照)。
対応する動的権限は SYSTEM_VARIABLES_ADMIN
です。
グループレプリケーションを含む、レプリケーションを開始および停止するアカウントを有効にします。
対応する動的権限は、通常のレプリケーションの場合は REPLICATION_SLAVE_ADMIN
、グループレプリケーションの場合は GROUP_REPLICATION_ADMIN
です。
(MySQL 8.0.23 の)CHANGE REPLICATION SOURCE TO
ステートメント、(MySQL 8.0.23 の前の)CHANGE MASTER TO
ステートメントおよび CHANGE REPLICATION FILTER
ステートメントを使用できます。
対応する動的権限は REPLICATION_SLAVE_ADMIN
です。
PURGE BINARY LOGS
および BINLOG
ステートメントを使用してバイナリログ制御を有効にします。
対応する動的権限は BINLOG_ADMIN
です。
ビューまたはストアドプログラムの実行時に有効な承認 ID を設定できるようにします。 この権限を持つユーザーは、ビューまたはストアドプログラムの DEFINER
属性で任意のアカウントを指定できます。
対応する動的権限は SET_USER_ID
です。
CREATE SERVER
、ALTER SERVER
および DROP SERVER
ステートメントの使用を有効にします。
mysqladmin debug コマンドの使用を有効にします。
InnoDB
暗号化キーのローテーションを有効にします。
対応する動的権限は ENCRYPTION_KEY_ADMIN
です。
バージョントークンのユーザー定義関数の実行を有効にします。
対応する動的権限は VERSION_TOKEN_ADMIN
です。
ロールの付与と取消し、GRANT
ステートメントの WITH ADMIN OPTION
句の使用、および ROLES_GRAPHML()
関数からの結果の空でない <graphml>
要素コンテンツを有効にします。
対応する動的権限は ROLE_ADMIN
です。
SUPER
以外のアカウントに対して許可されていないクライアント接続の制御を有効にします:
KILL
ステートメントまたは mysqladmin kill コマンドを使用して、他のアカウントに属するスレッドを強制終了できます。 (アカウントは常に独自のスレッドを強制終了できます。)
サーバーは、SUPER
クライアントの接続時に init_connect
システム変数の内容を実行しません。
サーバーは、max_connections
システム変数で構成された接続制限に達した場合でも、SUPER
クライアントからの接続を受け入れます。
オフラインモード (offline_mode
が有効) のサーバーは、次のクライアントリクエスト時に SUPER
クライアント接続を終了せず、SUPER
クライアントからの新しい接続を受け入れます。
read_only
システム変数が有効な場合でも、更新を実行できます。 これは、明示的なテーブル更新、およびテーブルを暗黙的に更新する GRANT
や REVOKE
などのアカウント管理ステートメントの使用に適用されます。
前述の接続制御操作に対応する動的権限は、CONNECTION_ADMIN
です。
セクション25.7「ストアドプログラムバイナリロギング」 で説明されているように、バイナリロギングが有効になっている場合は、ストアドファンクションを作成または変更するために SUPER
権限が必要になることもあります。
トリガー操作を有効にします。 テーブルのトリガーを作成、削除、実行または表示するには、そのテーブルに対するこの権限が必要です。
トリガーが (トリガーに関連付けられたテーブルに対して INSERT
、UPDATE
または DELETE
ステートメントを実行する権限を持つユーザーによって) アクティブ化された場合、トリガーの実行には、トリガーを定義したユーザーがそのテーブルに対する TRIGGER
権限を持っている必要があります。
データベース内のテーブルで行を更新できます。
この権限指定子は、「「権限なし」」を表します。 GRANT
でグローバルレベルで使用され、権限リスト内の特定のアカウント権限に名前を付けずに WITH GRANT OPTION
などの句を指定します。 SHOW GRANTS
には、アカウントに権限レベルの権限がないことを示す USAGE
が表示されます。
サーバーに組み込まれている静的権限とは対照的に、動的権限は実行時に定義されます。 次のリストでは、MySQL で使用可能な各動的権限について説明します。
ほとんどの動的権限は、サーバーの起動時に定義されます。 その他は、権限の説明に示されているように、特定のコンポーネントまたはプラグインによって定義されます。 このような場合、権限を定義するコンポーネントまたはプラグインが有効になっていないかぎり、権限は使用できません。
特定の SQL ステートメントには、ここに示されているよりも具体的な権限要件がある場合もあります。 そのような場合、該当するステートメントの説明で詳細を示します。
APPLICATION_PASSWORD_ADMIN
(MySQL 8.0.14 で追加)
デュアルパスワード機能の場合、この権限により、自分のアカウントに適用される ALTER USER
ステートメントおよび SET PASSWORD
ステートメントに RETAIN CURRENT PASSWORD
句および DISCARD OLD PASSWORD
句を使用できます。 ほとんどのユーザーは 1 つのパスワードのみを必要とするため、自分のセカンダリパスワードを操作するにはこの権限が必要です。
アカウントがすべてのアカウントのセカンダリパスワードの操作を許可される場合は、APPLICATION_PASSWORD_ADMIN
ではなく CREATE USER
権限を付与する必要があります。
デュアルパスワードの使用の詳細は、セクション6.2.15「パスワード管理」 を参照してください。
監査ログ構成を有効にします。 この権限は、audit_log
プラグインによって定義されます。セクション6.4.5「MySQL Enterprise Audit」 を参照してください。
LOCK INSTANCE FOR BACKUP
ステートメントの実行およびパフォーマンススキーマ log_status
テーブルへのアクセスを有効にします。
BACKUP_ADMIN
の他に、log_status
テーブルに対する SELECT
権限もアクセスに必要です。
以前のバージョンから MySQL 8.0 へのインプレースアップグレードを実行すると、RELOAD
権限を持つユーザーに BACKUP_ADMIN
権限が自動的に付与されます。
PURGE BINARY LOGS
および BINLOG
ステートメントを使用してバイナリログ制御を有効にします。
バイナリログファイルおよびリレーログファイルの暗号化をアクティブまたは非アクティブにするシステム変数 binlog_encryption
の設定を有効にします。 この機能は、BINLOG_ADMIN
、SYSTEM_VARIABLES_ADMIN
または SESSION_VARIABLES_ADMIN
権限では提供されません。 サーバーの再起動時にバイナリログマスターキーを自動的にローテーションする関連システム変数 binlog_rotate_encryption_master_key_at_startup
には、この権限は必要ありません。
CLONE
ステートメントの実行を有効にします。 BACKUP_ADMIN
および SHUTDOWN
権限が含まれます。
KILL
ステートメントまたは mysqladmin kill コマンドを使用して、他のアカウントに属するスレッドを強制終了できます。 (アカウントは常に独自のスレッドを強制終了できます。)
クライアント接続に関連するシステム変数の設定、またはクライアント接続に関連する制限の回避を有効にします。 CONNECTION_ADMIN
は、次のシステム変数の影響に適用されます:
init_connect
: サーバーは、CONNECTION_ADMIN
クライアントの接続時に init_connect
システム変数の内容を実行しません。
max_connections
: サーバーは、max_connections
システム変数で構成された接続制限に達した場合でも、CONNECTION_ADMIN
クライアントからの接続を受け入れます。
offline_mode
: オフラインモード (offline_mode
が有効) のサーバーは、次のクライアントリクエスト時に CONNECTION_ADMIN
クライアント接続を終了せず、CONNECTION_ADMIN
クライアントからの新しい接続を受け入れます。
read_only
: read_only
システム変数が有効な場合でも、更新を実行できます。 これは、明示的なテーブル更新、およびテーブルを暗黙的に更新する GRANT
や REVOKE
などのアカウント管理ステートメントの使用に適用されます。
InnoDB
暗号化キーのローテーションを有効にします。
ユーザーは、任意のユーザーのファイアウォールルールを管理できます。 この権限は、MYSQL_FIREWALL
プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。
ユーザーが独自のファイアウォールルールを更新できるようにします。 この権限は、MYSQL_FIREWALL
プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。
FLUSH_OPTIMIZER_COSTS
(MySQL 8.0.23 で追加)
FLUSH OPTIMIZER_COSTS
ステートメントの使用を有効にします。
FLUSH_STATUS
(MySQL 8.0.23 で追加)
FLUSH STATUS
ステートメントの使用を有効にします。
FLUSH_TABLES
(MySQL 8.0.23 で追加)
FLUSH TABLES
ステートメントの使用を有効にします。
FLUSH_USER_RESOURCES
(MySQL 8.0.23 で追加)
FLUSH USER_RESOURCES
ステートメントの使用を有効にします。
START GROUP REPLICATION
および STOP GROUP REPLICATION
ステートメントを使用してグループレプリケーションを開始および停止し、group_replication_consistency
システム変数のグローバル設定を変更し、group_replication_set_write_concurrency()
および group_replication_set_communication_protocol()
UDF を使用できるようにします。 レプリケーショングループのメンバーであるサーバーの管理に使用されるアカウントにこの権限を付与します。
アカウントが redo ログアーカイブをアクティブ化および非アクティブ化できるようにします。
ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG
ステートメントを使用して redo ロギングを有効または無効にします。 MySQL 8.0.21 で導入されました。
redo ロギングの無効化を参照してください。
特定の NDB Cluster に参加するとすぐに、ユーザーまたは役割とその権限をすべての NDB
対応 MySQL サーバー間で共有および同期できるようにします。 この権限は、NDB
ストレージエンジンが有効になっている場合にのみ使用できます。
指定されたユーザーまたはロールに対して行われた権限の変更または取消しは、接続されているすべての MySQL サーバー (SQL ノード) とただちに同期化されます。 異なる SQL ノードから発生した権限に影響する複数のステートメントが、すべての SQL ノードで同じ順序で実行されることは保証されないことに注意してください。 このため、すべてのユーザー管理は単一の指定された SQL ノードから実行することを強くお薦めします。
NDB_STORED_USER
はグローバル権限であり、ON *.*
を使用して付与または取り消す必要があります。 この権限に他のスコープを設定しようとすると、エラーになります。 この権限は、ほとんどのアプリケーションユーザーおよび管理ユーザーに付与できますが、mysql.session@localhost
や mysql.infoschema@localhost
などのシステム予約アカウントには付与できません。
NDB_STORED_USER
権限を付与されたユーザーは、この権限を持つロールと同様に、NDB
に格納されます (したがって、すべての SQL ノードで共有されます)。 NDB_STORED_USER
を持つロールのみを付与されたユーザーは、NDB
には格納されません。各 NDB
格納ユーザーには、権限を明示的に付与する必要があります。
NDB
でのこの動作の詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照してください。
NDB_STORED_USER
権限は NDB 8.0.18 以降で使用できます。
SYSTEM_VARIABLES_ADMIN
も持っているユーザーの場合、PERSIST_RO_VARIABLES_ADMIN
を使用すると、SET PERSIST_ONLY
を使用してグローバルシステム変数をデータディレクトリの mysqld-auto.cnf
オプションファイルに永続化できます。 このステートメントは SET PERSIST
と似ていますが、ランタイムグローバルシステム変数の値は変更されません。 これにより、SET PERSIST_ONLY
は、サーバーの起動時にのみ設定できる読取り専用システム変数の構成に適しています。
セクション5.1.9.1「システム変数権限」も参照してください。
アカウントをレプリケーションチャネルの PRIVILEGE_CHECKS_USER
として機能させ、mysqlbinlog 出力で BINLOG
ステートメントを実行できるようにします。 CHANGE REPLICATION SOURCE TO
(MySQL 8.0.23 から) または CHANGE MASTER TO
(MySQL 8.0.23 より前) を使用して割り当てられたアカウントにこの権限を付与して、レプリケーションチャネルのセキュリティコンテキストを提供し、それらのチャネルでレプリケーションエラーを処理します。 REPLICATION_APPLIER
権限と同様に、レプリケーションチャネルで受信したトランザクションまたは mysqlbinlog 出力に含まれるトランザクションを実行するために必要な権限をアカウントに付与して、影響を受けるテーブルを更新する必要があります。 詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。
アカウントがレプリケーションソースサーバーに接続し、START REPLICA | SLAVE
および STOP REPLICA | SLAVE
ステートメントを使用してレプリケーションを開始および停止し、CHANGE REPLICATION SOURCE TO
ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO
ステートメント (MySQL 8.0.23 より前) および CHANGE REPLICATION FILTER
ステートメントを使用します。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。 この権限はグループレプリケーションには適用されません。そのためには GROUP_REPLICATION_ADMIN
を使用します。
リソースグループの作成、変更および削除、およびリソースグループへのスレッドとステートメントの割当てで構成されるリソースグループ管理を有効にします。 この権限を持つユーザーは、リソースグループに関連する操作を実行できます。
リソースグループへのスレッドとステートメントの割り当てを有効にします。 この権限を持つユーザーは、SET RESOURCE GROUP
ステートメントおよび RESOURCE_GROUP
オプティマイザヒントを使用できます。
ロールの付与と取消し、GRANT
ステートメントの WITH ADMIN OPTION
句の使用、および ROLES_GRAPHML()
関数からの結果の空でない <graphml>
要素コンテンツを有効にします。 mandatory_roles
システム変数の値を設定するために必要です。
管理接続のみを許可するネットワークインタフェースへの接続を有効にします (セクション5.1.12.1「接続インタフェース」 を参照)。
SESSION_VARIABLES_ADMIN
(MySQL 8.0.14 で追加)
ほとんどのシステム変数では、セッション値の設定に特別な権限は必要なく、すべてのユーザーが現在のセッションに影響を与えることができます。 一部のシステム変数では、セッション値を設定すると、現在のセッションの外部に影響を与える可能性があるため、操作が制限されます。 これらの場合、SESSION_VARIABLES_ADMIN
権限により、ユーザーはセッション値を設定できます。
システム変数が制限されていて、セッション値を設定するために特別な権限が必要な場合、変数の説明にその制限が示されます。 例として、binlog_format
、sql_log_bin
および sql_log_off
があります。
SESSION_VARIABLES_ADMIN
が追加された MySQL 8.0.14 より前は、SYSTEM_VARIABLES_ADMIN
または SUPER
権限を持つユーザーのみが制限付きセッションシステム変数を設定できます。
SESSION_VARIABLES_ADMIN
権限は、SYSTEM_VARIABLES_ADMIN
および SUPER
権限のサブセットです。 これらの権限のいずれかを持つユーザーは、制限付きセッション変数の設定も許可され、効果的には SESSION_VARIABLES_ADMIN
を意味するため、SESSION_VARIABLES_ADMIN
を明示的に付与する必要はありません。
セクション5.1.9.1「システム変数権限」も参照してください。
ビューまたはストアドプログラムの実行時に有効な承認 ID を設定できるようにします。 この権限を持つユーザーは、ビューまたはストアドプログラムの DEFINER
属性として任意のアカウントを指定できます。
MySQL 8.0.22 では、SET_USER_ID
を使用して、(おそらく誤って) ストアドオブジェクトが孤立したり、現在孤立しているストアドオブジェクトを採用する原因となる操作を防ぐために設計されたセキュリティチェックをオーバーライドすることもできます。 詳細は、孤立したストアドオブジェクトを参照してください。
SHOW_ROUTINE
(MySQL 8.0.20 で追加)
ユーザーがルーチン DEFINER
として指定されていないストアドルーチン (ストアドプロシージャーおよびストアドファンクション) の定義およびプロパティーにアクセスできるようにします。 このアクセスには、次のものが含まれます:
INFORMATION_SCHEMA.ROUTINES
テーブルの内容。
SHOW CREATE FUNCTION
および SHOW CREATE PROCEDURE
ステートメント。
SHOW FUNCTION CODE
および SHOW PROCEDURE CODE
ステートメント。
SHOW FUNCTION STATUS
および SHOW PROCEDURE STATUS
ステートメント。
MySQL 8.0.20 より前では、ユーザーが定義しなかったルーチンの定義にアクセスするには、グローバルな SELECT
権限が必要です。これは非常に広範です。 8.0.20 の時点では、代わりに、ルーチン定義へのアクセスを許可するより制限されたスコープを持つ特権として SHOW_ROUTINE
を付与できます。 (つまり、管理者は、それを必要としないユーザーからグローバル SELECT
を廃棄し、かわりに SHOW_ROUTINE
を付与できます。) これにより、アカウントは広範囲の権限を必要とせずにストアドルーチンをバックアップできます。
SYSTEM_USER
(MySQL 8.0.16 で追加)
SYSTEM_USER
権限は、システムユーザーを通常のユーザーと区別します:
SYSTEM_USER
権限を持つユーザーはシステムユーザーです。
SYSTEM_USER
権限を持たないユーザーは通常のユーザーです。
SYSTEM_USER
権限は、特定のユーザーが他の権限を適用できるアカウント、およびそのユーザーが他のアカウントから保護されているかどうかに影響します:
システムユーザーは、システムアカウントと通常アカウントの両方を変更できます。 つまり、通常のアカウントに対して特定の操作を実行する適切な権限を持つユーザーは、システムアカウントに対しても操作を実行するように SYSTEM_USER
を所有することで有効になります。 システムアカウントは、通常のユーザーではなく、適切な権限を持つシステムユーザーのみが変更できます。
適切な権限を持つ通常のユーザーは通常のアカウントを変更できますが、システムアカウントは変更できません。 通常のアカウントは、適切な権限を持つシステムユーザーと通常のユーザーの両方が変更できます。
詳細は、セクション6.2.11「アカウントカテゴリ」を参照してください。
SYSTEM_USER
権限によってシステムアカウントに付与される通常のアカウントによる変更からの保護は、mysql
システムスキーマに対する権限を持つ通常のアカウントには適用されないため、そのスキーマの付与テーブルを直接変更できます。 完全保護のために、mysql
スキーマ権限を通常のアカウントに付与しないでください。 通常アカウントによる操作からのシステムアカウントの保護を参照してください。
次の操作およびサーバーの動作に影響します:
実行時のシステム変数の変更を有効にします:
SET GLOBAL
および SET PERSIST
を使用して、グローバルシステム変数に対するサーバー構成の変更を有効にします。
ユーザーが PERSIST_RO_VARIABLES_ADMIN
も持っている場合、SET PERSIST_ONLY
を使用してグローバルシステム変数に対するサーバー構成の変更を有効にします。
特別な権限を必要とする制限付きセッションシステム変数の設定を有効にします。 実際には、SYSTEM_VARIABLES_ADMIN
は、SESSION_VARIABLES_ADMIN
を明示的に付与せずに SESSION_VARIABLES_ADMIN
を暗黙的に意味します。
セクション5.1.9.1「システム変数権限」も参照してください。
グローバルトランザクション特性の変更を有効にします (セクション13.3.7「SET TRANSACTION ステートメント」 を参照)。
TABLE_ENCRYPTION_ADMIN
(MySQL 8.0.16 で追加)
table_encryption_privilege_check
が有効な場合に、ユーザーがデフォルトの暗号化設定をオーバーライドできるようにします。スキーマおよび一般テーブルスペースの暗号化デフォルトの定義 を参照してください。
バージョントークンのユーザー定義関数の実行を有効にします。 この権限は、version_tokens
プラグインによって定義されます。セクション5.6.6「バージョントークン」 を参照してください。
XA RECOVER
ステートメントの実行を有効にします。セクション13.3.8.1「XA トランザクション SQL ステートメント」 を参照してください。
MySQL 8.0 より前は、すべてのユーザーが XA RECOVER
ステートメントを実行して、未処理の準備済 XA トランザクションの XID 値を検出できたため、XA トランザクションを開始したユーザー以外のユーザーによる XA トランザクションのコミットまたはロールバックが発生する可能性がありました。 MySQL 8.0 では、XA RECOVER
は XA_RECOVER_ADMIN
権限を持つユーザーにのみ許可されます。これは、それを必要とする管理ユーザーにのみ付与されることが予想されます。 たとえば、XA アプリケーションがクラッシュし、ロールバックできるようにアプリケーションによって開始された未処理のトランザクションを検索する必要がある場合などです。 この権限要件により、ユーザーは自分以外の未処理の準備済 XA トランザクションの XID 値を検出できなくなります。 XA トランザクションを開始したユーザーが XID を認識しているため、XA トランザクションの通常のコミットまたはロールバックには影響しません。
アカウントには必要な権限のみを付与することをお勧めします。 FILE
権限と管理権限の付与については十分に注意するようにしてください。
FILE
を使用すると、MySQL サーバーがサーバーホスト上で読み取ることができるファイルをデータベーステーブルに読み込むことができます。 これにはすべてのユーザーが読み取り可能なすべてのファイルと、サーバーのデータディレクトリ内のファイルが含まれます。 そのあと、SELECT
を使用してそのテーブルにアクセスし、テーブルの内容をクライアントホストに送信することができます。
GRANT OPTION
を使用すると、ユーザーは他のユーザーに権限を付与できます。 異なる権限を持つ 2 人のユーザーが GRANT OPTION
権限を持っていれば、権限を組み合わせることができます。
ALTER
を使用すると、テーブルの名前を変更して権限システムを再変換できます。
SHUTDOWN
では、サーバーを終了することで、他のユーザーに対するサービスを完全に拒否できます。
PROCESS
を使用すると、パスワードを設定または変更するステートメントを含む、現在実行中のステートメントのプレーンテキストを表示できます。
SUPER
を使用すると、他のセッションを終了したり、サーバーの動作方法を変更できます。
mysql
システムデータベース自体に付与された権限を使用して、パスワードおよびその他のアクセス権限情報を変更できます:
パスワードは暗号化されて保管されているため、悪意のあるユーザーは単純にそのパスワードを見てプレーンテキストパスワードを知ることはできません。 ただし、mysql.user
システムテーブルの authentication_string
カラムへの書込みアクセス権を持つユーザーは、アカウントパスワードを変更し、そのアカウントを使用して MySQL サーバーに接続できます。
mysql
システムデータベースに付与された INSERT
または UPDATE
を使用すると、ユーザーはそれぞれ権限を追加したり、既存の権限を変更できます。
mysql
システムデータベース用の DROP
を使用すると、ユーザーはリモート権限テーブルまたはデータベース自体を使用できます。
MySQL では、静的権限および動的権限がサポートされています:
静的権限はサーバーに組み込まれています。 これらは常にユーザーアカウントに付与でき、登録解除できません。
動的権限は、実行時に登録および登録解除できます。 これは可用性に影響: 登録されていない動的権限は付与できません。
たとえば、SELECT
および INSERT
権限は静的で常に使用可能ですが、動的権限は、それを実装するコンポーネントが有効になっている場合にのみ使用可能になります。
このセクションの残りの部分では、動的権限が MySQL でどのように機能するかについて説明します。 この説明では、「「コンポーネント」」という用語を使用しますが、プラグインにも同様に適用されます。
サーバー管理者は、動的権限を定義するサーバーコンポーネントに注意する必要があります。 MySQL ディストリビューションの場合、動的権限を定義するコンポーネントのドキュメントには、これらの権限が記載されています。
サードパーティコンポーネントでも動的権限を定義できます。管理者は、これらの権限を理解し、サーバー操作が競合または危険にさらされる可能性のあるコンポーネントをインストールしないでください。 たとえば、両方で同じ名前の権限が定義されている場合、あるコンポーネントが別のコンポーネントと競合します。 コンポーネント開発者は、コンポーネント名に基づいて接頭辞を持つ権限名を選択することで、この発生の可能性を減らすことができます。
サーバーは、登録された動的権限のセットをメモリー内に内部的に保持します。 サーバーの停止時に登録解除が発生します。
通常、動的権限を定義するコンポーネントは、インストール時に初期化シーケンス中にそれらを登録します。 アンインストール時に、コンポーネントは登録されている動的権限を登録解除しません。 (これは現在の演習であり、要件ではありません。 つまり、コンポーネントは、登録した権限でいつでも登録解除できますが、できません。)
すでに登録されている動的権限を登録しようとしても、警告やエラーは発生しません。 次の一連のステートメントについて考えてみます:
INSTALL COMPONENT 'my_component'; UNINSTALL COMPONENT 'my_component'; INSTALL COMPONENT 'my_component';
最初の INSTALL COMPONENT
ステートメントでは、コンポーネント my_component
によって定義された権限は登録されますが、UNINSTALL COMPONENT
では登録解除されません。 2 番目の INSTALL COMPONENT
ステートメントでは、登録するコンポーネント権限はすでに登録されていますが、警告やエラーは発生しません。
動的権限はグローバルレベルでのみ適用されます。 サーバーは、ユーザーアカウントへの動的権限の現在の割当てに関する情報を mysql.global_grants
システムテーブルに格納します:
サーバーは、(--skip-grant-tables
オプションが指定されていないかぎり) サーバーの起動時に global_grants
で指定された権限を自動的に登録します。
GRANT
および REVOKE
ステートメントによって、global_grants
の内容が変更されます。
global_grants
にリストされている動的権限割当ては永続的です。 サーバーの停止時には削除されません。
例: 次のステートメントは、レプリカに対するレプリケーション (グループレプリケーションを含む) の制御およびシステム変数の変更に必要な権限をユーザー u1
に付与します:
GRANT REPLICATION_SLAVE_ADMIN, GROUP_REPLICATION_ADMIN, BINLOG_ADMIN ON *.* TO 'u1'@'localhost';
付与された動的権限は、SHOW GRANTS
ステートメントおよび INFORMATION_SCHEMA
USER_PRIVILEGES
テーブルからの出力に表示されます。
グローバルレベルの GRANT
および REVOKE
の場合、静的として認識されない名前付き権限は、現在登録されている動的権限のセットに対してチェックされ、見つかった場合は付与されます。 それ以外の場合は、不明な権限識別子を示すエラーが発生します。
GRANT
および REVOKE
の場合、グローバルレベルの ALL [PRIVILEGES]
の意味には、すべての静的グローバル権限と、現在登録されているすべての動的権限が含まれます:
グローバルレベルの GRANT ALL
では、すべての静的グローバル権限および現在登録されているすべての動的権限が付与されます。 GRANT
ステートメントの実行後に登録された動的権限は、どのアカウントにも遡及的に付与されません。
グローバルレベルの REVOKE ALL
は、付与されているすべての静的グローバル権限および付与されているすべての動的権限を取り消します。
FLUSH PRIVILEGES
ステートメントは、動的権限割当てのために global_grants
テーブルを読み取り、そこで見つかった未登録の権限を登録します。
MySQL Server によって提供される動的権限および MySQL ディストリビューションに含まれるコンポーネントの詳細は、セクション6.2.2「MySQL で提供される権限」 を参照してください。
MySQL 8.0 では、以前に SUPER
権限を必要としていた多くの操作も、より限定された有効範囲の動的権限に関連付けられています。 (これらの権限の詳細は、セクション6.2.2「MySQL で提供される権限」 を参照してください。) このような各操作は、SUPER
ではなく、関連付けられた動的権限を付与することで、アカウントに対して許可できます。 この変更により、DBA は SUPER
の付与を回避し、ユーザー権限を許可されている操作により厳密に調整できるため、セキュリティが向上します。 SUPER
は非推奨になりました。将来のバージョンの MySQL で削除される予定です。
SUPER
の削除が発生すると、SUPER
を付与されたアカウントが適切な動的権限に移行されないかぎり、以前は SUPER
を必要としていた操作は失敗します。 次の手順を使用して、SUPER
を削除する前にアカウントの準備が整うようにその目標を達成します:
次のクエリーを実行して、SUPER
が付与されているアカウントを識別します:
SELECT GRANTEE FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'SUPER';
前述のクエリーで識別されたアカウントごとに、SUPER
が必要な操作を決定します。 次に、これらの操作に対応する動的権限を付与し、SUPER
を取り消します。
たとえば、バイナリログのパージおよびシステム変数の変更に'u1'@'localhost'
で SUPER
が必要な場合、次のステートメントによってアカウントに必要な変更が加えられます:
GRANT BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'u1'@'localhost'; REVOKE SUPER ON *.* FROM 'u1'@'localhost';
適用可能なすべてのアカウントを変更した後、最初のステップの INFORMATION_SCHEMA
クエリーで空の結果セットが生成されます。