GRANT (ロール) ステートメント
この形式の GRANT ステートメントはロールを、ユーザー、グループ、またはその他のロールに付与します。
呼び出し
このステートメントは、アプリケーション・プログラムに組み込んだり、動的 SQL ステートメントを使用して発行したりすることができます。 これは、DYNAMICRULES の実行動作がパッケージに効力を持つ場合にのみ、動的に準備できる実行可能ステートメントです (SQLSTATE 42509)。
許可
ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかの権限が含まれていなければなりません。
- ロールに対する WITH ADMIN OPTION
- SECADM 権限
構文
説明
- ROLE role-name,...
- 付与する 1 つ以上のロールを指定します。 role-name はそれぞれ、現行サーバーの既存のロールを識別するものでなければなりません (SQLSTATE 42704)。
- TO
- ロールを付与する対象のユーザーを指定します。
- USER
- authorization-name がユーザーであることを指定します。
- GROUP
- authorization-name がグループであることを指定します。
- ROLE
- authorization-name が現行サーバーにおける既存のロールを識別することを指定します (SQLSTATE 42704)。
- authorization-name,...
- 1 つ以上のユーザー、グループ、またはロールの許可 ID のリストを指定します。 この許可 ID のリストに、このステートメントを発行するユーザーの許可 ID を含めることはできません (SQLSTATE 42502)。
- PUBLIC
- 指定されたロールをユーザーのセット (許可 ID) に付与します。
- WITH ADMIN OPTION
- 指定された authorization-name が他のユーザーに対して role-name を付与したり、取り消したりできるようにします。 また、コメントをロールに関連付けられるようにもします。 指定された authorization-name によるロールのドロップは許可しません。
規則
- 指定した authorization-name ごとに、キーワード USER、GROUP、および ROLE のいずれも指定されていない場合には次のようになります。
- インスタンスに対して有効なセキュリティー・プラグインによって authorization-name の状況を判別できなければ、エラーが戻されます (SQLSTATE 56092)。
- authorization-name が、データベースでは ROLE として定義されており、かつオペレーティング・システムでは GROUP または USER のいずれかとして定義されている場合、エラーが戻されます (SQLSTATE 56092)。
- 有効になっているセキュリティー・プラグインに従って authorization-name が USER と GROUP の両方として定義されている場合は、エラーが戻されます (SQLSTATE 56092)。
- 有効になっているセキュリティー・プラグインに従って authorization-name が USER としてのみ定義されている場合、または未定義の場合は、USER であると見なされます。
- 有効になっているセキュリティー・プラグインに従って authorization-name が GROUP としてのみ定義されている場合は、GROUP であると見なされます。
- authorization-name がデータベースで ROLE としてのみ定義されている場合には、ROLE であると見なされます。
- 1 つのロールを別のロールに付与することによってロールの階層を構築できます。 ただし、循環は使用できません (SQLSTATE 428GF)。 例えば、ロール R1 を別のロール R2 に付与する場合はロール R2 (または R2 を含む他のロール Rn) を R1 に付与することはできません。 それによって循環が生成される可能性があるからです。
- USER、GROUP、または ROLE の名前を「SYS」という文字で始めることはできず、「ACCESSCTRL」、 「DATAACCESS」、「DBADM」、「NONE」、「NULL」、「PUBLIC」、「SECADM」、「SQLADM」、「SCHEMAADM」、または「WLMADM」のいずれかにすることもできません (SQLSTATE 42939)。
注
- ロール R1 を別のロール R2 に付与すると、R2 に R1 が含まれることになります。
- DBADM 権限を PUBLIC に付与することはできません。
したがって、次のようになります。
- R1 が DBADM 権限を直接または間接的に保持する場合、PUBLIC へのロール R1 の付与は失敗します (SQLSTATE 42508)。
- 次のステートメントを発行済みの場合、ロール R1 は DBADM 権限を直接保持します。
GRANT DBADM ON DATABASE TO ROLE R1 - 次のステートメントを発行済みの場合、ロール R1 は DBADM 権限を間接的に保持します。
GRANT DBADM ON DATABASE TO ROLE R2 GRANT ROLE R2 TO ROLE R1
- 次のステートメントを発行済みの場合、ロール R1 は DBADM 権限を直接保持します。
- ロール R2 が直接または間接的に PUBLIC に付与される場合、ロール R2 へのロール R1 (DBADM 権限を保持する) の付与は失敗します (SQLSTATE 42508)。
- 次のステートメントを発行済みの場合、ロール R2 は PUBLIC に直接付与されます。
GRANT ROLE R2 TO PUBLIC - 次のステートメントを発行済みの場合、ロール R2 は PUBLIC に間接的に付与されます。
GRANT ROLE R2 TO ROLE R3 GRANT ROLE R3 TO PUBLIC
- 次のステートメントを発行済みの場合、ロール R2 は PUBLIC に直接付与されます。
- R1 が DBADM 権限を直接または間接的に保持する場合、PUBLIC へのロール R1 の付与は失敗します (SQLSTATE 42508)。
- スキーマ・レベルの権限 (SCHEMAADM、スキーマ ACCESSCTRL、スキーマ DATAACCESS、スキーマ LOAD) を PUBLIC に付与することはできません。
- グループに付与される特権: グループに付与される特権は、以下に対する許可検査には使用されません。
- パッケージ内の静的 DML ステートメント
- CREATE VIEW ステートメントの処理過程での基本表
- マテリアライズ照会表の CREATE TABLE ステートメントの処理過程での基本表
- SQL ルーチンの作成
- トリガーの作成
例
- 例 1: ロール INTERN をロール DOCTOR に、さらにロール DOCTOR をロール SPECIALIST に付与します。
GRANT ROLE INTERN TO ROLE DOCTOR GRANT ROLE DOCTOR TO ROLE SPECIALIST - 例 2: ロール INTERN を PUBLIC に付与します。
GRANT ROLE INTERN TO PUBLIC - 例 3: ロール SPECIALIST をユーザー BOB とグループ TORONTO に付与します。
GRANT ROLE SPECIALIST TO USER BOB, GROUP TORONTO
