Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.1Mb
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


6.2.1 MySQL で提供される権限

MySQL では、さまざまなコンテキストおよびさまざまな動作レベルに適用される権限が提供されます。

  • 管理権限によって、ユーザーは MySQL サーバーの動作を管理できます。これらの権限は特定のデータベースに固有でないため、グローバルです。

  • データベース権限は、データベースおよびデータベース内のすべてのオブジェクトに適用されます。これらの権限は、特定のデータベースに付与したり、すべてのデータベースに適用されるようにグローバルに付与したりすることができます。

  • テーブル、インデックス、ビュー、ストアドルーチンなどのデータベースオブジェクト向けの権限は、データベース内の特定のオブジェクト、データベース内の特定タイプのすべてのオブジェクト (たとえばデータベース内のすべてのテーブル)、またはすべてのデータベース内の特定タイプのすべてのオブジェクトにグローバルに付与することができます。

アカウント権限に関する情報は、mysql データベース内の userdbtables_privcolumns_priv、および procs_priv テーブルに格納されます (セクション6.2.2「権限システム付与テーブル」を参照してください)。MySQL サーバーはこれらのテーブルの内容を起動時にメモリーに読み取り、セクション6.2.6「権限変更が有効化される時期」に示す条件でこれらを再ロードします。アクセス制御決定は、付与テーブルのインメモリーコピーに基づきます。

MySQL の一部のリリースでは、新たな権限や機能を追加するために付与テーブルの構造に変更を加えているものもあります。すべての新しい機能を確実に活用できるようにするには、新しいバージョンの MySQL に更新するときに常に付与テーブルを更新して、最新の構造を持つようにします。セクション4.4.7「mysql_upgrade — MySQL テーブルのチェックとアップグレード」を参照してください。

次の表には、GRANT および REVOKE ステートメント内で SQL レベルで使用される権限名のほか、付与テーブル内の各権限に関連付けられたカラムおよび権限が適用されるコンテキストが示されています。

表 6.2 GRANT および REVOKE に対して許容可能な権限

権限 カラム コンテキスト
CREATE Create_priv データベース、テーブル、またはインデックス
DROP Drop_priv データベース、テーブル、またはビュー
GRANT OPTION Grant_priv データベース、テーブル、またはストアドルーチン
LOCK TABLES Lock_tables_priv データベース
REFERENCES References_priv データベースまたはテーブル
EVENT Event_priv データベース
ALTER Alter_priv テーブル
DELETE Delete_priv テーブル
INDEX Index_priv テーブル
INSERT Insert_priv テーブルまたはカラム
SELECT Select_priv テーブルまたはカラム
UPDATE Update_priv テーブルまたはカラム
CREATE TEMPORARY TABLES Create_tmp_table_priv テーブル
TRIGGER Trigger_priv テーブル
CREATE VIEW Create_view_priv ビュー
SHOW VIEW Show_view_priv ビュー
ALTER ROUTINE Alter_routine_priv ストアドルーチン
CREATE ROUTINE Create_routine_priv ストアドルーチン
EXECUTE Execute_priv ストアドルーチン
FILE File_priv サーバーホストでのファイルアクセス
CREATE TABLESPACE Create_tablespace_priv サーバー管理
CREATE USER Create_user_priv サーバー管理
PROCESS Process_priv サーバー管理
PROXY proxies_priv テーブルを参照 サーバー管理
RELOAD Reload_priv サーバー管理
REPLICATION CLIENT Repl_client_priv サーバー管理
REPLICATION SLAVE Repl_slave_priv サーバー管理
SHOW DATABASES Show_db_priv サーバー管理
SHUTDOWN Shutdown_priv サーバー管理
SUPER Super_priv サーバー管理
ALL [PRIVILEGES]   サーバー管理
USAGE   サーバー管理

次のリストには、MySQL で使用可能な各権限の一般的な説明が提供されています。特定の SQL ステートメントには、ここに示されているよりも具体的な権限要件がある場合もあります。そのような場合、該当するステートメントの説明で詳細を示します。

  • ALL または ALL PRIVILEGES 権限指定子は、短縮形です。これは、特定の権限レベルで使用可能なすべての権限 (GRANT OPTION を除く) を表します。たとえば、グローバルまたはテーブルレベルで ALL を付与すると、すべてのグローバル権限またはテーブルレベルのすべての権限が付与されます。

  • ALTER 権限は、テーブルの構造を変更するための ALTER TABLE の使用を可能にします。ALTER TABLE には CREATE および INSERT 権限も必要です。テーブルを名前変更するには、古いテーブル側で ALTER および DROP と、新しいテーブル側で ALTERCREATE、および INSERT 権限が必要です。

  • ストアドルーチン (プロシージャーおよび関数) を変更または削除するには、ALTER ROUTINE 権限が必要です。

  • CREATE 権限は、新規データベースおよびテーブルの作成を可能にします。

  • ストアドルーチン (プロシージャーおよび関数) を作成するには、CREATE ROUTINE 権限が必要です。

  • テーブルスペースおよびログファイルグループを作成、変更、または削除するには、CREATE TABLESPACE 権限が必要です。

  • CREATE TEMPORARY TABLES 権限は、CREATE TEMPORARY TABLE ステートメントを使用した一時テーブルの作成を可能にします。

    MySQL 5.6.3 の時点では、セッションによって一時テーブルが作成されると、サーバーはテーブル上の権限チェックを追加実行しません。セッションの作成によって、DROP TABLEINSERTUPDATESELECT などのあらゆる操作をテーブル上で実行できます。

    この動作の 1 つの影響として、現在のユーザーが一時テーブルを作成する権限を持たなくても、セッションが一時テーブルを操作できるということがあります。現在のユーザーが CREATE TEMPORARY TABLES 権限を持たないが、CREATE TEMPORARY TABLES を持つユーザーの権限で実行して一時テーブルを作成する、DEFINER コンテキストのストアドプロシージャーを実行できるとします。プロシージャーの実行中、セッションは定義側ユーザーの権限を使用します。プロシージャーが復帰したあと、有効な権限は現在のユーザーの権限に戻り、これによって引き続き一時テーブルを表示し、一時テーブルに対してあらゆる操作を実行できることになります。

    MySQL 5.6.3 より前では、INSERTUPDATESELECT などの一時テーブル上でのほかの操作には、一時テーブルを格納するデータベースに対する操作について、または同じ名前の非一時テーブルについての追加の権限が必要です。

    一時テーブルと非一時テーブルの権限を分離するための、この状況についての一般的な回避策は、一時テーブルを使用するための専用データベースを作成することです。そうすることで、そのデータベースについて、CREATE TEMPORARY TABLES 権限と、ユーザーによって実行される一時テーブル操作に必要なほかのすべての権限を、そのユーザーに付与することができます。

  • CREATE USER 権限は、CREATE USERDROP USERRENAME USER、および REVOKE ALL PRIVILEGES の使用を可能にします。

  • CREATE VIEW 権限は、CREATE VIEW の使用を可能にします。

  • DELETE 権限は、データベースのテーブルからの行の削除を可能にします。

  • DROP 権限は、既存のデータベース、テーブル、およびビューのドロップを可能にします。パーティション化されたテーブルで ALTER TABLE ... DROP PARTITION ステートメントを使用するには DROP 権限が必要です。DROP 権限は TRUNCATE TABLE のためにも必要です。mysql データベースに対する DROP 権限をユーザーに付与すると、MySQL アクセス権限が格納されているデータベースをユーザーが削除することができます。

  • イベントスケジューラについてのイベントを作成、変更、削除、または表示するには、EVENT 権限が必要です。

  • ストアドルーチン (プロシージャーおよび関数) を実行するには、EXECUTE 権限が必要です。

  • FILE 権限は、LOAD DATA INFILE および SELECT ... INTO OUTFILE ステートメントと LOAD_FILE() 関数を使用するサーバーホスト上でファイルの読み取りおよび書き込みを実行するための許可をユーザーに与えます。FILE 権限を持つユーザーは、すべてのユーザーから読み取り可能であるか、MySQL サーバーによって読み取り可能なサーバーホスト上のすべてのファイルを読み取ることができます。(このことは暗黙的に、データベースディレクトリ内のあらゆるファイルにサーバーからアクセスできるため、ユーザーはそれらのすべてのファイルを読み取ることができることを意味します。)さらに FILE 権限によって、ユーザーは MySQL サーバーが書き込みアクセス権限を持つあらゆるディレクトリに新しいファイルを作成できます。これは、権限テーブルを実装するファイルを格納するサーバーのデータディレクトリを含みます。セキュリティー対策として、サーバーは既存のファイルを上書きしません。

    ファイルを読み取りおよび書き込みできる場所を制限するには、secure_file_priv システムを特定のディレクトリに設定します。セクション5.1.4「サーバーシステム変数」を参照してください。

  • GRANT OPTION 権限によって、ユーザーは自分自身が所有する権限をほかのユーザーに付与したり、ほかのユーザーから削除したりすることができます。

  • INDEX 権限によって、ユーザーはインデックスを作成またはドロップできます。INDEX は既存のテーブルに適用されます。テーブルに対する CREATE 権限を持つ場合、CREATE TABLE ステートメントにインデックス定義を含めることも可能です。

  • INSERT 権限は、データベースのテーブルへの行の挿入を可能にします。ANALYZE TABLEOPTIMIZE TABLEREPAIR TABLE などのテーブル保守に関するステートメントにも、INSERT 権限が必要です。

  • LOCK TABLES 権限は、ユーザーが SELECT 権限を持つテーブルをロックするために、明示的な LOCK TABLES ステートメントの使用を可能にします。これには、ロックされたテーブルをほかのセッションから読み取らせないようにする書き込みロックの使用が含まれます。

  • PROCESS 権限は、サーバー内で実行するスレッドについての情報の表示に関係します (つまり、セッションによって実行されるステートメントについての情報)。この権限は、SHOW PROCESSLIST または mysqladmin processlist を使用して、ほかのアカウントに属するスレッドを表示することを可能にし、自分自身のスレッドを表示することもできます。PROCESS 権限は、SHOW ENGINE の使用も可能にします。

  • PROXY 権限によって、ユーザーは別のユーザーになりすましたり、別のユーザーとして認識されるようにしたりすることができます。セクション6.3.9「プロキシユーザー」を参照してください。

  • REFERENCES 権限は現在使用されていません。

  • RELOAD 権限は、FLUSH ステートメントの使用を可能にします。また、これは FLUSH 操作 (flush-hostsflush-logsflush-privilegesflush-statusflush-tablesflush-threadsrefresh、および reload) と同等な mysqladmin コマンドを使用可能にします。

    reload コマンドは、付与テーブルをメモリーにリロードするようにサーバーに指示します。flush-privilegesreload のシノニムです。refresh コマンドは、ログファイルを閉じて再オープンし、すべてのテーブルをフラッシュします。ほかの flush-xxx コマンドは refresh に類似した機能を実行しますが、より具体的であるため一部の状況では好ましい場合があります。たとえば、ログファイルだけをフラッシュするときは、refresh よりも flush-logs を選択することをお勧めします。

  • REPLICATION CLIENT 権限は、SHOW MASTER STATUS および SHOW SLAVE STATUS の使用を可能にします。MySQL 5.6.6 以降では、これは SHOW BINARY LOGS ステートメントの使用も可能にします。

  • REPLICATION SLAVE 権限は、マスターとしての現在のサーバーに接続するときにスレーブサーバーが使用するアカウントに対して与えるようにしてください。この権限がない場合、スレーブは、マスターサーバー上のデータベースに対して実行された更新をリクエストすることができません。

  • SELECT 権限によって、ユーザーはデータベース内のテーブルから行を選択できます。SELECT ステートメントで SELECT 権限が必要となるのは、ステートメントがテーブルから実際にレコードを取得する場合です。一部の SELECT ステートメントはテーブルにアクセスしないため、あらゆるデータベースへのアクセス権がなくても実行できます。たとえば、テーブルを参照しない式を評価するための単純な計算機として SELECT を使用することができます。

    SELECT 1+1;
    SELECT PI()*2;
    

    SELECT 権限は、カラム値を読み取るほかのステートメントについても必要です。たとえば、UPDATE ステートメントの代入 col_name=expr の右辺で参照されるカラムや、DELETE または UPDATE ステートメントの WHERE 句で指定されるカラムについて、SELECT が必要です。

  • SHOW DATABASES 権限によって、アカウントは SHOW DATABASE ステートメントを発行することでデータベース名を表示することができます。この権限を持たないアカウントには、アカウントが一部の権限を持つデータベースしか表示されず、サーバーが --skip-show-database オプションで起動されている場合はステートメントを一切使用できません。すべてのグローバル権限は、データベースに対する権限だということに注意してください。

  • SHOW VIEW 権限は、SHOW CREATE VIEW の使用を可能にします。

  • SHUTDOWN 権限は、mysqladmin shutdown コマンドの使用を可能にします。対応する SQL ステートメントはありません。

  • SUPER 権限によって、アカウントはほかのアカウントに属するスレッドを強制終了するための CHANGE MASTER TOKILL、または mysqladmin kill (自分のスレッドは常に強制終了できます)、PURGE BINARY LOGS、グローバルシステム変数を変更するための SET GLOBAL を使用した構成変更、mysqladmin debug コマンド、ロギングの有効化または無効化、read_only システム変数が有効な場合の更新の実行、スレーブサーバー上でのレプリケーションの開始と停止、ストアドプログラムおよびビューの DEFINER 属性内のすべてのアカウントの指定を使用することができ、ユーザーは max_connections システム変数によって制御される接続制限に達している場合でも (一度) 接続することができます。

    バイナリロギングを有効にした場合にストアドファンクションを作成または変更するとき、セクション20.7「ストアドプログラムのバイナリロギング」に記載されているように SUPER 権限がやはり必要になることがあります。

  • TRIGGER 権限はトリガー操作を有効にします。テーブルのトリガーを作成、削除、または実行するには、そのテーブルに対してこの権限を持つ必要があります。

  • UPDATE 権限は、データベース内のテーブルの行の更新を可能にします。

  • USAGE 権限指定子は、権限なしを表します。これは GRANT と一緒にグローバルレベルで使用されて、既存のアカウント権限に影響を及ぼすことなくリソース制限や SSL 特性などのアカウント属性を変更します。

アカウントには必要な権限のみを付与することをお勧めします。FILE 権限と管理権限の付与については十分に注意するようにしてください。

  • FILE 権限を悪用して、MySQL サーバーがサーバーホスト上で読み取ることができるあらゆるファイルをデータベーステーブルから読み取ることができます。これにはすべてのユーザーが読み取り可能なすべてのファイルと、サーバーのデータディレクトリ内のファイルが含まれます。そのあと、SELECT を使用してそのテーブルにアクセスし、テーブルの内容をクライアントホストに送信することができます。

  • GRANT OPTION 権限によって、ユーザーはほかのユーザーに権限を付与することができます。異なる権限を持つ 2 人のユーザーが GRANT OPTION 権限を持っていれば、権限を組み合わせることができます。

  • ALTER 権限を使用して、テーブルの名前を変更することによって権限システムを壊すことができます。

  • SHUTDOWN 権限を悪用して、サーバーを終了することによって、ほかのユーザーへのサービスを完全に妨害することができます。

  • PROCESS 権限は、パスワードの設定や変更を行うステートメントなどを含め、現在実行中のステートメントのプレーンテキストを表示することができます。

  • SUPER 権限は、ほかのセッションを終了したり、サーバーの動作方法を変更したりするために使用できます。

  • mysql データベース自体に付与した権限を使用して、パスワードおよびその他のアクセス権限情報を変更することができます。パスワードは暗号化されて保管されているため、悪意のあるユーザーは単純にそのパスワードを見てプレーンテキストパスワードを知ることはできません。ただし、user テーブルの Password カラムへの書き込みアクセス権限を持つユーザーは、アカウントのパスワードを変更し、そのアカウントを使用して MySQL サーバーに接続することができます。


User Comments
  Posted by Dietrich Feist on November 25, 2003
One workaround to give users permissions on temporary tables that you don't want to give them on regular tables is the following. We just have to keep in mind that users have the same access rights on temporary tables that they have on all tables in a particular database:

1) create a dedicated database for temporary tables:

mysql> CREATE DATABASE tmp;

2) Give your users all the access privileges that they need to create and use temporary tables:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, DROP, ALTER, CREATE TEMPORARY TABLES ON tmp.* TO user@localhost;

Be sure that you do not give them CREATE or GRANT privileges!

3) Have you users create all temporary tables in that 'tmp' database instead of the current database:

mysql> USE mydb
mysql> CREATE TEMPORARY TABLE tmp.dummy SELECT * from mytable;

Your users have to explicitly call their temporary tables as tmp.<tablename> in all requests. There is no problem if two users use the same name for a temporary table since they will not be able to see each other's temporary tables. You can also put the 'tmp' database on a dedicated disk.
  Posted by Randy Austin on August 25, 2009
One side-effect of priv_super is that users with priv_super are allowed to write to the database, regardless of the setting of the read_only global variables.

  Posted by David Tonhofer on December 24, 2010
A little query to write the wide privilege table out in narrower form:

SELECT password, host, user,
CONCAT(Select_priv, Lock_tables_priv) AS selock,
CONCAT(Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv) AS modif,
CONCAT(Grant_priv, References_priv, Index_priv, Alter_priv) AS meta,
CONCAT(Create_tmp_table_priv, Create_view_priv, Show_view_priv) AS views,
CONCAT(Create_routine_priv, Alter_routine_priv, Execute_priv) AS funcs,
CONCAT(Repl_slave_priv, Repl_client_priv) AS replic,
CONCAT(Super_priv, Shutdown_priv, Process_priv, File_priv, Show_db_priv, Reload_priv) AS admin
FROM USER ORDER BY user, host;

+-------------------------------------------+-----------+--------+--------+-------+------+-------+-------+--------+--------+
| password | host | user | selock | modif | meta | views | funcs | replic | admin |
+-------------------------------------------+-----------+--------+--------+-------+------+-------+-------+--------+--------+
| *......... | localhost | backup | YY | NNNNN | NNNN | NNN | NNN | NN | NNNNNN |
| *......... | localhost | nagios | XX | NNNNN | NNNN | NNN | NNN | NN | NNNNNN |
| *......... | 127.0.0.1 | root | YY | YYYYY | YYYY | YYY | YYY | YY | YYYYYY |
| *......... | localhost | root | YY | YYYYY | YYYY | YYY | YYY | YY | YYYYYY |
| | localhost | wheel | NY | NNNNN | NNNN | NNN | NNN | NN | NNNNNY |
+-------------------------------------------+-----------+--------+--------+-------+------+-------+-------+--------+--------+

  Posted by Eli Skoczylas on November 6, 2012
The FILE privilege can not be restricted to a single table, so the syntax for it is:

GRANT FILE ON *.* TO 'username'@'host'....

Hope that saves someone else from having to dig for the answer.
  Posted by Tss Tss on November 8, 2012
Please note that "escape" clause doesnot work in view

If you have WHERE condition " like 'ABC/_%' escape '/' " and you mean select string like 'ABC_'+'something' you'll suddenly find that you got 'ABC'+'something' instead.

  Posted by Jörg Brühe on May 12, 2014
We just found that a user account needs the "process" privilege to collect performance values from the MySQL server. In our case, these are values for Graphite/Icinga, as provided by "show status".
  Posted by Peter Burns on January 26, 2015
Note that although REFERENCES privilege is currently "unused", granting it on a table allows the user to query the information_schema database for column names etc. We found this useful for creating database documentation from the schema without needing to grant even SELECT privilege to the user (our wiki, in fact).
Sign Up Login You must be logged in to post a comment.