モジュール java.base
パッケージ java.security

クラスAccessController

java.lang.Object
java.security.AccessController
@Deprecated(since="17", forRemoval=true) public final class AccessController extends Object
削除予定のため非推奨: このAPI要素は、将来のバージョンで削除される可能性があります。
このクラスは、非推奨であり、将来のリリースで削除される可能性があります。「セキュリティ・マネージャ」と組み合わせて使用すると便利です。 したがって、このクラスも非推奨となり、削除される可能性があります。 Security Managerまたはこのクラスの交換はありません。

AccessControllerクラスは、アクセス制御の操作およびディシジョンに使用されます。

具体的には、AccessControllerクラスは3つの目的で使用されます:

  • 現在有効なセキュリティ・ポリシーに基づいて、重要なシステム・リソースへのアクセスが許可されるか、拒否されるかを決定する。
  • コードを「特権」が与えられたものとしてマークし、以降のアクセスの決定に影響を与える。
  • アクセス制御が保存したコンテキストに関して用意される別のコンテキストから決定できるように、現在の呼出し側コンテキストの「スナップショット」を取得する。

checkPermissionメソッドは、指定されたアクセス権によって示されるアクセス要求が許可されるか、拒否されるかを決定します。 呼出しの例を次に示します。 この例では、checkPermissionは、/tempディレクトリのtestFileというファイルへの読込み権を許可するかどうかを決定します。 


 FilePermission perm = new FilePermission("/temp/testFile", "read");
 AccessController.checkPermission(perm);

要求されたアクセス権が許可される場合、checkPermissionは何もしないで復帰します。 拒否された場合、AccessControlExceptionがスローされます。 リクエストされた権限のタイプが正しくないか、無効な値が含まれている場合、AccessControlExceptionもスローされます。 可能な場合には、そうした情報が提供されます。 現在のスレッドが呼出し元1から呼出し元2を経て呼出し元mまでの順番でトラバースしたとします。 呼出し元mはcheckPermissionメソッドを呼び出しました。 このとき、checkPermissionメソッドは次のアルゴリズムに基づいて、アクセスが許可されるか拒否されるかを決定します。 

 
 for (int i = m; i > 0; i--) {

     if (caller i's domain does not have the permission)
         throw AccessControlException

     else if (caller i is marked as privileged) {
         if (a context was specified in the call to doPrivileged)
             context.checkPermission(permission)
         if (limited permissions were specified in the call to doPrivileged) {
             for (each limited permission) {
                 if (the limited permission implies the requested permission)
                     return;
             }
         } else
             return;
     }
 }

 // Next, check the context inherited when the thread was created.
 // Whenever a new thread is created, the AccessControlContext at
 // that time is stored and associated with the new thread, as the
 // "inherited" context.

 inheritedContext.checkPermission(permission);

呼出し側は、特権コードとしてマークできます(doPrivilegedおよび次の説明を参照)。 アクセス制御を決定する場合、checkPermissionメソッドは、コンテキスト引数のないdoPrivilegedの呼出しによって特権コードとしてマークされた呼出し側に届いたときに、検査を中止します(コンテキスト引数については、次の説明を参照)。 その呼出し元のドメインが指定されたアクセス権を持っていて、少なくとも1つのアクセス権制限引数(あれば)に要求されたアクセス権が含まれている場合、checkPermissionはそれ以上のチェックを行わずに正常復帰し、要求されたアクセスが許可されていることを示します。 そのドメインが指定されたアクセス権を持たない場合は、通常は例外が発行されます。 呼出し元のドメインが指定されたアクセス権を持っているが、doPrivilegedの呼出し時に指定されたアクセス権制限引数にそれが含まれていない場合は、呼出し元が存在しなくなるか、別のdoPrivileged呼出しが要求されたアクセス権と一致して正常に復帰するまで、アクセス権のチェックが続行されます。

次に、特権機能の通常の使い方を説明します。 「特権付き」ブロックからの戻り値が必要ない場合は、次のようにします。 

 
 somemethod() {
     ...normal code here...
     AccessController.doPrivileged(new PrivilegedAction<Void>() {
         public Void run() {
             // privileged code goes here, for example:
             System.loadLibrary("awt");
             return null; // nothing to return
         }
     });
     ...normal code here...
 }

PrivilegedActionは、runという名前の単一のメソッドを持つインタフェースです。 上記の例は、そのインタフェースの実装の作成方法を示しています。つまり、runメソッドの具象実装が提供されます。 doPrivilegedをコールすると、PrivilegedAction実装のインスタンスが渡されます。 doPrivilegedメソッドは、権限の有効化後にPrivilegedAction実装からrunメソッドをコールし、doPrivileged戻り値(この例では無視されます)としてrunメソッドの戻り値を返します。

次に、値を返す必要がある場合の例を示します。 

 
 somemethod() {
     ...normal code here...
     String user = AccessController.doPrivileged(
         new PrivilegedAction<String>() {
         public String run() {
             return System.getProperty("user.name");
             }
         });
     ...normal code here...
 }

runメソッドで実行したアクションが「チェック」例外(メソッドのthrows節に表示されている例外)をスローする可能性がある場合には、PrivilegedActionインタフェースの代わりにPrivilegedExceptionActionインタフェースを使用する必要があります。 

 
 somemethod() throws FileNotFoundException {
     ...normal code here...
     try {
         FileInputStream fis = AccessController.doPrivileged(
         new PrivilegedExceptionAction<FileInputStream>() {
             public FileInputStream run() throws FileNotFoundException {
                 return new FileInputStream("someFile");
             }
         });
     } catch (PrivilegedActionException e) {
         // e.getException() should be an instance of FileNotFoundException,
         // as only "checked" exceptions will be "wrapped" in a
         // PrivilegedActionException.
         throw (FileNotFoundException) e.getException();
     }
     ...normal code here...
  }

特権構造の使用には細心の注意を払って、特権コード・セクションをできるだけ小さくしてください。 Permission引数を渡して「特権」のスコープをさらに制限できます(次を参照)。

checkPermissionは、常に現在実行しているスレッドのコンテキスト内でセキュリティ・チェックを行います。 しかし実際には、指定されたコンテキスト内で行うセキュリティ・チェックを、別のコンテキスト内から(たとえば、ワーカー・スレッド内から)行わなければならない場合もあります。 この状況では、getContextメソッドおよびAccessControlContextクラスが提供されます。 getContextメソッドは、現在の呼出し元のコンテキストの"スナップショット"を取得し、それを戻すAccessControlContextオブジェクトに配置します。 呼出しの例を次に示します。 


 AccessControlContext acc = AccessController.getContext()

AccessControlContext自体には、現在の実行スレッドではなく、コンテキストitのカプセル化に基づいてアクセス・ディシジョンを行うcheckPermissionメソッドがあります。 したがって、別のコンテキスト内のコードは、以前に保存されたAccessControlContextオブジェクトでそのメソッドをコールできます。 呼出しの例を次に示します。 


 acc.checkPermission(permission)

また、コンテキストをどのアクセス権で検査するかが、事前には不明な場合があります。 このような場合は、コンテキストを取得するdoPrivilegedメソッドを使用できます。 追加のPermissionパラメータを渡すことによって、特権コードのスコープを制限することもできます。 

 
 somemethod() {
     AccessController.doPrivileged(new PrivilegedAction<Object>() {
         public Object run() {
             // Code goes here. Any permission checks within this
             // run method will require that the intersection of the
             // caller's protection domain and the snapshot's
             // context have the desired permission. If a requested
             // permission is not implied by the limiting FilePermission
             // argument then checking of the thread continues beyond the
             // caller of doPrivileged.
         }
     }, acc, new FilePermission("/temp/*", read));
     ...normal code here...
 }

AllPermissionのインスタンスのPermission制限引数を渡すことは、Permission制限引数なしで同等のdoPrivilegedを呼び出すことと同じです。 長さゼロのPermissionの配列を渡すと、コードの特権が無効になるため、そのdoPrivilegedメソッドの呼出し元を超えて常にチェックが続行されます。

導入されたバージョン:
1.2
関連項目: