サーバーは接続を受け入れると、アクセス制御のステージ 2 に入ります。 接続を介して発行するリクエストごとに、実行する操作がサーバーによって決定され、権限が十分かどうかがチェックされます。 ここで、付与テーブルの権限カラムが役立ちます。 これらの権限は、user
, global_grants
, db
, tables_priv
, columns_priv
テーブルまたは procs_priv
テーブルのいずれかから取得できます。 (各付与テーブルに存在するカラムを一覧表示する セクション6.2.3「付与テーブル」 を参照すると役立つ場合があります。)
user
テーブルおよび global_grants
テーブルは、グローバル権限を付与します。 特定のアカウントのこれらのテーブルの行は、デフォルトデータベースが何であるかに関係なく、グローバルに適用されるアカウント権限を示します。 たとえば、user
テーブルで DELETE
権限が付与されている場合、サーバーホスト上の任意のデータベース内の任意のテーブルから行を削除できます。 user
テーブルの権限は、データベース管理者などの権限を必要とするユーザーに対してのみ付与するのが賢明です。 他のユーザーの場合は、user
テーブルのすべての権限を'N'
に設定したままにし、より具体的なレベルでのみ権限を付与します (特定のデータベース、テーブル、カラムまたはルーチンの場合)。 データベース権限をグローバルに付与することもできますが、部分的な取消しを使用して、特定のデータベースでの実行を制限します (セクション6.2.12「部分取消しを使用した権限の制限」 を参照)。
db
テーブルは、データベース固有の権限を付与します。 このテーブルのスコープカラムの値は、次の形式を取ることができます。
ブランクの
User
値は匿名ユーザーに一致します。 ブランク以外の値は文字どおりに一致し、ユーザー名にワイルドカードはありません。ワイルドカード文字
%
および_
は、Host
カラムおよびDb
カラムで使用できます。 これらはLIKE
演算子で実行されるパターンマッチング演算と同じ意味を持ちます。 権限を付与するときにいずれかの文字を文字どおりに使用する場合、文字をバックスラッシュでエスケープする必要があります。 たとえば、アンダースコア文字 (_
) をデータベース名の一部として含めるには、GRANT
ステートメントで\_
として指定します。'%'
またはブランクのHost
値は、「任意のホスト」を意味します。'%'
またはブランクのDb
値は、「任意のデータベース」を意味します。
サーバーは user
テーブルを読み取るのと同時に、db
テーブルをメモリーに読み取ってソートします。 サーバーは、Host
、Db
、および User
スコープカラムに基づき db
テーブルをソートします。 user
テーブルと同様に、ソートでは最も固有の値が最初に、最も固有の値が最後に配置され、サーバーで一致する行が検索されると、最初に検出された一致が使用されます。
tables_priv
、columns_priv
、および procs_priv
テーブルは、テーブル固有、カラム固有、およびルーチン固有の権限を付与します。 これらのテーブルのスコープカラムの値は、次の形式を取ることができます。
ワイルドカード文字
%
および_
をHost
カラムで使用できます。 これらはLIKE
演算子で実行されるパターンマッチング演算と同じ意味を持ちます。'%'
またはブランクのHost
値は、「任意のホスト」を意味します。Db
、Table_name
、Column_name
、およびRoutine_name
カラムは、ワイルドカードを含めたり、ブランクにしたりすることができません。
サーバーは、Host
、Db
、および User
カラムに基づき、tables_priv
、columns_priv
、および procs_priv
テーブルをソートします。 これは db
テーブルのソートと同様ですが、Host
カラムのみワイルドカードを含めることができるため、よりシンプルです。
サーバーはソート済みテーブルを使用して、サーバーが受け取るリクエストを検証します。 SHUTDOWN
や RELOAD
などの管理権限を必要とするリクエストの場合、サーバーは user
テーブルと global_privilege
テーブルのみをチェックします。これらは管理権限を指定する唯一のテーブルであるためです。 サーバーは、それらのテーブル内のアカウントの行がリクエストされた操作を許可し、それ以外の場合はアクセスを拒否する場合にアクセス権を付与します。 たとえば、ユーザーが mysqladmin shutdown を実行したいが、user
テーブル行によって SHUTDOWN
権限がユーザーに付与されていない場合、サーバーは db
テーブルさえもチェックせずにアクセスを拒否します。 (後者のテーブルには Shutdown_priv
カラムが含まれていないため、チェックする必要はありません。)
データベース関連のリクエスト (INSERT
、UPDATE
など) の場合、サーバーはまず user
テーブルの行のユーザーグローバル権限をチェックします (部分的な取消しによる権限制限は少なくなります)。 リクエストされた操作が行で許可されている場合、アクセス権限が付与されます。 user
テーブルのグローバル権限が不十分な場合、サーバーは db
テーブルからユーザーデータベース固有の権限を判別します:
サーバーは、
db
テーブルを参照しHost
、Db
、およびUser
カラムの一致がないかチェックします。Host
およびUser
カラムは、接続するユーザーのホスト名および MySQL ユーザー名に突き合わせされます。Db
カラムは、ユーザーがアクセスしようとしているデータベースに突き合わせされます。Host
およびUser
に該当する行がない場合、アクセスは拒否されます。
db
テーブルの行によって付与されたデータベース固有の権限を確認すると、サーバーは、user
テーブルによって付与されたグローバル権限にそれらを追加します。 その結果、リクエストされた操作が許可される場合、アクセス権限が付与されます。 そうでない場合、サーバーは続けて tables_priv
および columns_priv
テーブル内でユーザーのテーブル権限およびカラム権限をチェックし、これらをユーザーの権限に追加し、結果に基づいてアクセスを許可または拒否します。 ストアドルーチン操作の場合、サーバーは tables_priv
および columns_priv
の代わりに procs_priv
テーブルを使用します。
ブール条件によって表現すると、ユーザーの権限を計算する方法についての前述の説明は、次のように要約できます。
global privileges
OR database privileges
OR table privileges
OR column privileges
OR routine privileges
グローバル権限が最初にリクエストされた操作に対して不十分であることがわかった場合、サーバーはこれらの権限を後でデータベース、テーブルおよびカラムの権限に追加する理由は明らかではありません。 この理由は、1 つのリクエストが複数のタイプの権限を必要とすることがあるためです。 たとえば、INSERT INTO ... SELECT
ステートメントを実行する場合、INSERT
および SELECT
権限が両方必要です。 user
テーブルの行が一方の権限をグローバルに付与し、db
テーブルの行が他方の権限を関連データベース専用に付与するような権限の場合があります。 この場合、リクエストを実行するために必要な権限を持っていますが、サーバーはグローバル権限またはデータベース権限のみからそれを通知できません。 結合された権限に基づいてアクセス制御を決定する必要があります。