このページは機械翻訳したものです。

6.2.7 アクセス制御、ステージ 2: リクエストの確認

サーバーは接続を受け入れると、アクセス制御のステージ 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 テーブルの行が他方の権限を関連データベース専用に付与するような権限の場合があります。 この場合、リクエストを実行するために必要な権限を持っていますが、サーバーはグローバル権限またはデータベース権限のみからそれを通知できません。 結合された権限に基づいてアクセス制御を決定する必要があります。