このabstractクラスは、すべてのアクセス権の上位クラスです。すべてのアクセス権に必要な必須機能を定義します。

アクセス権の各インスタンスは、通常、コンストラクタに1つ以上の文字列パラメータを渡すことによって生成されます。2つのパラメータを使う一般的なケースでは、通常、1つ目のパラメータは「ターゲットの名前」(アクセス権の目的のファイル名など)で、2つ目のパラメータは動作(ファイルに対する「読取り」動作など)です。通常、複数の動作のセットをカンマで区切った文字列の組み合わせで指定できます。

このクラスは、同一種のアクセス権のコレクションを持ちます。つまり、このクラスの各インスタンスは、同じタイプのアクセス権のみを持ちます。

このクラスは、異種のアクセス権のコレクションを保持するように設計されています。基本的に、このクラスはjava.security.PermissionCollectionオブジェクトのコレクションです。

前述したように、セキュリティ・ポリシーの内部状態は通常、各コード・ソースに関連するアクセス権オブジェクトによって表されます。しかし、Javaテクノロジの動的な性質を考慮すると、ポリシーが初期化された時点で、特定のアクセス権クラスを実装した実際のコードがまだロードされておらず、Javaアプリケーション環境に定義されていない可能性があります。たとえば、参照されたアクセス権クラスは、あとにロードされるJARファイル内にある可能性があります。

UnresolvedPermissionクラスは、こうした「未解決」のアクセス権を保持するために使用されます。同様に、java.security.UnresolvedPermissionCollectionクラスにはUnresolvedPermissionアクセス権のコレクションが保存されます。

アクセス制御の際に、以前は未解決であったものの、現在そのクラスがロードされているアクセス権のタイプがチェックされ、未解決のアクセス権が「解決」されて、適切なアクセス制御が決定されます。つまり、可能であれば、UnresolvedPermission内の情報に基づいて適切なクラス・タイプの新規オブジェクトのインスタンスが生成されます。UnresolvedPermissionはこの新規オブジェクトに置き換えられ、削除されます。この時点でも解決されないアクセス権は、セキュリティ・ポリシーで付与されない無効なアクセス権とみなされます。

このクラスのターゲットは、次のように指定されます。ここで、ディレクトリとファイルの名前は文字列で、空白文字を含むことはできません。

file
directory (same as directory/)
directory/file
directory/* (all files in this directory)
* (all files in the current directory)
directory/- (all files in the file system under this directory)
- (all files in the file system under the current directory)
"<<ALL FILES>>" (all files in the file system)

<<ALL FILES>>は特別な文字列で、システム内のすべてのファイルを表します。LinuxまたはmacOSでは、rootディレクトリ下のすべてのファイルを含みます。Windowsでは、すべてのドライブのすべてのファイルを含みます。

動作は、read、write、delete、およびexecuteです。ファイルのアクセス権を作成する有効なコード例を次に示します。

import java.io.FilePermission;

FilePermission p = new FilePermission("myfile", "read,write");
FilePermission p = new FilePermission("/home/gong/", "read");
FilePermission p = new FilePermission("/tmp/mytmp", "read,delete");
FilePermission p = new FilePermission("/bin/*", "execute");
FilePermission p = new FilePermission("*", "read");
FilePermission p = new FilePermission("/-", "read,execute");
FilePermission p = new FilePermission("-", "read,execute");
FilePermission p = new FilePermission("<<ALL FILES>>", "read");

このクラスのimpliesメソッドは、ファイル・システムを正確に解釈します。たとえば、FilePermission("/-", "read,execute")は、FilePermission("/home/gong/public_html/index.html", "read")を表し、FilePermission("bin/*", "execute")はFilePermission("bin/emacs19.31", "execute")を表します。

FilePermission p = new FilePermission("c:\\temp\\foo", "read");

"c:\temp\foo"

FilePermission p = new FilePermission("/home/gong/", "read");

FilePermission p = new FilePermission("/home/gong/myfile", "read");
FilePermission p = new FilePermission("/home/gong/*", "read");
FilePermission p = new FilePermission("/home/gong/-", "read");

このクラスは、ソケットを通じたネットワークへのアクセス権を表します。このクラスのターゲットはhostname:port_rangeの形式で指定します。hostnameは次の形式で指定します。

hostname (a single host)
IP address (a single host)
localhost (the local machine)
"" (equivalent to "localhost")
hostname.domain (a single host within the domain)
hostname.subdomain.domain
*.domain (all hosts in the domain)
*.subdomain.domain
* (all hosts)

つまり、ホストは、DNS名、数値のIPアドレス、"localhost" (ローカル・マシンの場合)、"" ("localhost"を指定するのと同じ)のどれかで表現されます。

DNS名によるホストの指定では、ワイルドカード*を1回のみ含めることができます。これを含める場合は、*.sun.comのように左端に置く必要があります。

port_rangeは次の形式で指定します。

N (a single port)
N- (all ports numbered N and above)
-N (all ports numbered N and below)
N1-N2 (all ports between N1 and N2, inclusive)

上の形式で、N、N1およびN2は、0から65535 (2^16-1)の範囲内の負でない整数です。

ソケットでの動作は、accept、connect、listenおよびresolve(これは基本的にDNSルックアップ)です。アクション「resolve」は、「accept」、「connect」および「listen」によって暗黙的に定義されます。つまり、ホストからの入力接続を待機または受け付けるか、ホストへの出力接続を開始できるユーザーは、リモート・ホストの名前をルックアップできるはずです。

次に、ソケット・アクセス権の例を示します。

import java.net.SocketPermission;

SocketPermission p = new SocketPermission("java.example.com","accept");
p = new SocketPermission("192.0.2.99","accept");
p = new SocketPermission("*.com","connect");
p = new SocketPermission("*.example.com:80","accept");
p = new SocketPermission("*.example.com:-1023","accept");
p = new SocketPermission("*.example.com:1024-","connect");
p = new SocketPermission("java.example.com:8000-9000",
         "connect,accept");
p = new SocketPermission("localhost:1024-",
          "accept,connect,listen");

BasicPermissionクラスはPermissionクラスを継承します。BasicPermissionと同じ命名規則に従うアクセス権の基底クラスとして使用できます。

BasicPermissionの名前は、「exitVM」、「setFactory」、「queuePrintJob」など、指定したアクセス権の名前です。命名規約は、階層的なプロパティ命名規約に従います。名前の末尾には「*」や「.*」を付けて、ワイルドカードを指定できます。たとえば、「java.*」や「*」は有効ですが、「*java」や「a*b」は無効です。

Permissionから継承したアクション文字列は使用しません。したがって、通常、BasicPermissionは名前付きアクセス権の基底クラスとして使用します(名前付きアクセス権は名前を持ちますが、アクション・リストは持ちません。ユーザーは名前付きアクセス権を持つ場合と、持たない場合があります。)サブクラスは、必要に応じてBasicPermissionの上位クラスでアクションを実装できます。

BasicPermissionサブクラスには、java.lang.RuntimePermission、java.security.SecurityPermission、java.util.PropertyPermission、java.net.NetPermissionなどがあります。

このクラスのターゲットは、基本的には、さまざまなプロパティ・ファイルのセットとしてのJavaプロパティの名前です。たとえば、java.home、os.nameプロパティがあります。ターゲットは、「*」(任意のプロパティ)、「a.*」(「a.」接頭辞を持つ名前の任意のプロパティ)、「a.b.*」などの形式で指定できます。ワイルドカードは、右端に1回だけ使用できます。

このクラスは、BasicPermissionに基づいてアクションを実装するBasicPermissionサブクラスの1つです。アクションはreadとwriteです。それぞれの意味は、次のように定義されます。「read」アクセス権は、java.lang.System内のgetPropertyメソッドを呼び出してプロパティ値を取得することを許可します。「write」アクセス権は、setPropertyメソッドを呼び出してプロパティ値を設定することを許可します。

RuntimePermissionのターゲットは任意の文字列で表現でき、このターゲットに関連する動作はありません。たとえば、RuntimePermission("exitVM")はJava仮想マシンを終了するアクセス権を表します。

次のターゲット名を使用できます。

createClassLoader
getClassLoader
setContextClassLoader
setSecurityManager
createSecurityManager
exitVM
setFactory
setIO
modifyThread
modifyThreadGroup
getProtectionDomain
readFileDescriptor
writeFileDescriptor
loadLibrary.{library name}
accessClassInPackage.{package name}
defineClassInPackage.{package name}
accessDeclaredMembers.{class name}
queuePrintJob

このクラスは、RuntimePermissionと同じ考え方に基づいており、アクセス権には動作がありません。このクラスのターゲットには、次のようなものがあります。

accessClipboard
accessEventQueue
listenToAllAWTEvents
showWindowWithoutWarningBanner

このクラスには次のターゲットがあり、動作はありません。

requestPasswordAuthentication
setDefaultAuthenticator
specifyStreamHandler

リフレクション操作のためのアクセス権クラスです。ReflectPermissionは、名前付きのアクセス権(RuntimePermissionと同様)で、動作はありません。現在定義されている唯一の名前はsuppressAccessChecksです。これは、リフレクトされたオブジェクトが使用される位置で実行される、Javaプログラミング言語の標準のアクセス・チェック(public、default (package)アクセス、protected、privateメンバーに対するチェック)を無効にします。

このクラスには次のターゲットがあり、動作はありません。

enableSubclassImplementation
enableSubstitution

SecurityPermissionsは、セキュリティ関連のオブジェクト(Security、Policy、Provider、Signer、Identityオブジェクトなど)へのアクセスを管理します。このクラスには次のターゲットがあり、動作はありません。

getPolicy
setPolicy
getProperty.{key}
setProperty.{key}
insertProvider.{provider name}
removeProvider.{provider name}
setSystemScope
setIdentityPublicKey
setIdentityInfo
printIdentity
addIdentityCertificate
removeIdentityCertificate
clearProviderProperties.{provider name}
putProviderProperty.{provider name}
removeProviderProperty.{provider name}
getSignerPrivateKey
setSignerKeyPair

このアクセス権では、すべてのアクセスが許可されます。すべての(つまり多数の)アクセスの許可が必要なタスクを行うシステム管理者の仕事を簡単にするために用意されています。セキュリティ・ポリシーにすべてのアクセス権を繰返し定義するのは効率的ではありません。AllPermissionは、将来定義される新しいアクセス権も許可します。

このアクセス権を与える場合は、十分な注意が必要です。

AuthPermissionでは、認証アクセス権と認証に関連するオブジェクト(Subject、SubjectDomainCombiner、LoginContextおよびConfiguration)を扱います。このクラスには次のターゲットがあり、動作はありません。

doAs
doAsPrivileged
getSubject
getSubjectFromDomainCombiner
setReadOnly
modifyPrincipals
modifyPublicCredentials
modifyPrivateCredentials
refreshCredential
destroyCredential
createLoginContext.{name}
getLoginConfiguration
setLoginConfiguration
refreshLoginConfiguration

前述したように、アクセス権は互いに比較されることがあります。このような比較を簡単に行えるように、各アクセス権クラスでimpliesメソッドを定義して、特定のアクセス権クラスと他のアクセス権クラスとの関係を表す必要があります。たとえば、java.io.FilePermission("/tmp/*", "read")はjava.io.FilePermission("/tmp/a.txt", "read")を暗示しますが、すべてのjava.net.NetPermissionを暗示しません。

一見しただけではわからない、暗黙の包含関係もあります。たとえば、あるアプレットにファイル・システム全体への書込みアクセス権を与えるとします。これにより、このアプレットには、JVM実行時環境を含むシステムのバイナリ・ファイルの書換えが許可されると考えられます。これは結果的に、そのアプレットにすべてのアクセス権を与えることを意味します。

別の例として、あるアプレットにクラス・ローダーを生成する実行時アクセス権を与える場合、クラス・ローダーはクリティカルな操作を実行できるので、結果的に、このアプレットにさらに多くのアクセス権を与えることになります。

「危険」を伴うアクセス権にはこれ以外に、システム・プロパティの設定を許可するもの、パッケージの定義やネイティブ・コード・ライブラリのローディングのための実行時アクセス権(Javaのセキュリティ構造はネイティブ・コード・レベルでの悪意のある動作を防ぐように設計されていないため)、およびAllPermissionがあります。

特定のアクセス権の割当てのリスクを列挙した表およびアクセス権を必要とするすべてのJDKの組込みメソッドの表など、アクセス権の詳細は、JDKでのアクセス権を参照してください。

新機能の追加またはjava.lang.RuntimePermissionなどのクラスへの追加のターゲット・キーワードの導入により、JDKに組み込まれているアクセス権を拡張することは、Oracleだけに許されています。これは一貫性を維持するために必要なことです。

新しくアクセス権を作成するには、次の例のような方法をお薦めします。ABC社のアプリケーション開発者が「TVを見る」ための新しいカスタムのアクセス権を作成するとします。

最初に、抽象クラスjava.security.Permission (またはそのサブクラスの1つ)を継承する新しいクラスcom.abc.Permission、およびcom.abc.Permissionを継承する新しいクラスcom.abc.TVPermissionを作成します。ほかのクラスのimpliesメソッドが正しく実装されるように注意してください。ただし、com.abc.TVPermissionは中間のcom.abc.Permissionがなくても、直接java.security.Permissionを継承することはできます。

public class com.abc.Permission extends java.security.Permission

public class com.abc.TVPermission extends com.abc.Permission

図1-10に、サブクラスの関係を示します。

図1-10 com.abc.TV.Permissionのサブクラスの関係

「図1-10 com.abc.TV.Permissionのサブクラスの関係」の説明

次に、アプリケーション・パッケージにそれらの新規クラスをインクルードします。

特定のコードにこの新しいタイプのアクセス権を許可する場合、各ユーザーはポリシー・ファイルにエントリを追加します。(ポリシー・ファイルの構文の詳細についてはあとのセクションで説明。)次に、5チャネルを見る(watch)アクセス権をhttp://example.com/のコードに付与するポリシー・ファイル・エントリの例を示します。

grant codeBase  "http://example.com/" {
    permission com.abc.TVPermission "channel-5", "watch";
}

アプリケーションのリソース管理コードで、アクセス権を与えるかどうかのチェックを行うときは、com.abc.TVPermissionオブジェクトをパラメータとしてAccessControllerのcheckPermissionメソッドを呼び出します。

   com.abc.TVPermission tvperm = new
        com.abc.TVPermission("channel-5", "watch");
   AccessController.checkPermission(tvperm);

新しいアクセス権を追加するときは、新しい(アクセス権)クラスを作成し、セキュリティ・マネージャに新しいメソッドを追加しないでください。(以前は、新しいタイプのアクセスのチェックを有効にするためにはSecurityManagerクラスに新しいメソッドを追加する必要がありました。)

「channel-1:13」や「channel-*」など、より難解なTVPermissionsを許可するには、これらの擬似名のセマンティックスの扱いを知っているTVPermissionCollectionオブジェクトを実装する必要がある場合があります。

新しいコードがアクセス制御の組込みアルゴリズムを実行するためには、AccessControllerクラスのcheckPermissionメソッドを呼び出してアクセス権チェックを起動します。ClassLoaderやSecurityManagerがあるかどうかについては、必ずしも調べる必要はありません。ただし、インストールされているセキュリティ・マネージャ・クラスにそのアルゴリズムを任せる場合は、SecurityManager.checkPermissionメソッドを呼び出します。

Policyのリファレンス実装では、1つまたは複数のポリシー構成ファイルからポリシーを指定できます。構成ファイルは、特定のコード・ソースからのコードに許可されるアクセス権を示します。各構成ファイルは、UTF-8方式でエンコードする必要があります。

ポリシー構成ファイルは、エントリのリストで構成されます。ここには、1つのkeystoreエントリと、0個以上のgrantエントリを含めることができます。

キーストアは、秘密キーと、対応する公開キーを認証するX.509証明書チェーンなどのデジタル証明書が格納されたデータベースです。キーストアの作成と管理には、keytoolユーティリティを使用します。ポリシー構成ファイルで指定されているキーストアは、そのファイルのgrantエントリで指定されている署名者の公開キーを照合するために使用されます。署名者の別名を指定しているgrantエントリがある場合、またはプリンシパルの別名を指定しているgrantエントリがある場合は、ポリシー構成ファイルにkeystoreエントリを記述する必要があります。

現在、ポリシー・ファイルで指定できるkeystoreエントリは1つだけで、2つ目以降のkeystoreエントリは無視されるため、ファイルのgrantエントリの外であれば、どこに指定してもかまいません。構文は次のとおりです。

keystore "some_keystore_url", "keystore_type";

ここで、some_keystore_urlにはキーストアのURL位置を指定し、keystore_typeにはキーストアのタイプを指定します。この指定は任意で行います。指定しない場合、キーストアのタイプは、セキュリティ・プロパティ・ファイルのkeystore.typeプロパティで指定されたものと見なされます。

URLは、ポリシー・ファイルがある場所からの相対位置を表します。たとえば、セキュリティ・プロパティ・ファイルの中でポリシー・ファイルが次のように指定されているとします。

policy.url.1=http://foo.bar.example.com/blah/some.policy

また、このポリシー・ファイルには、次のエントリがあるとします。

keystore ".keystore";

この場合、キーストアは次の場所からロードされます。

http://foo.bar.example.com/blah/.keystore

URLに絶対位置を指定することもできます。

キーストアの型は、キーストア情報のストレージ形式とデータ形式を定義するとともに、キーストア内の秘密キーとキーストア自体の整合性を保護するために使われるアルゴリズムを定義します。Oracle JDKのデフォルトのキーストア・タイプはPKCS12です。

ポリシー・ファイルの各grantエントリは、本質的には1つのCodeSourceとそのアクセス権で構成されます。実際には、CodeSourceは1つのURLと証明書のセットで構成されますが、ポリシー・ファイルのエントリの内容はURLと署名者名のリストです。システムは、指定された署名者の証明書を決定するためにキーストアを調べた後で、対応するCodeSourceを生成します。

ポリシー・ファイルの各grantエントリは、次の形式のどれかです。ここで先頭のgrantは予約語で、新しいエントリの開始を示し、カッコの中にはオプション項目が示されます。各エントリ内の先頭のpermissionも予約語で、そのエントリ内で新しいアクセス権の記述が開始されることを示します。各grantエントリは、指定したコード・ソースとプリンシパルに一連のアクセス権を与えます。

grant [SignedBy "signer_names"] [, CodeBase "URL"]
      [, Principal [principal_class_name] "principal_name"]
      [, Principal [principal_class_name] "principal_name"] ... {
    permission permission_class_name [ "target_name" ] 
               [, "action"] [, SignedBy "signer_names"];
    permission ...
};

カンマの直前または直後には、空白文字を入れてもかまいません。アクセス権クラスの名前は、Javaの完全修飾形のクラス名(java.io.FilePermissionなど)でなければならず、省略(FilePermissionなど)はできません。

動作のフィールドは、省略可能なオプション・フィールドで、アクセス権クラスが動作を必要としない場合には省略できます。このフィールドを指定する場合は、必ずターゲット・フィールドの直後に置きます。

CodeBase URLの正確な意味は、最後の文字に依存します。末尾が「/」のCodeBaseは、指定されたディレクトリ内のすべてのクラス・ファイル(JARファイルを除く)を示します。末尾が「/*」のCodeBaseは、そのディレクトリ内にあるすべてのファイル(クラス・ファイルとJARファイルの両方)を示します。末尾が「/-」のCodeBaseは、指定されたディレクトリとその下の全サブディレクトリ内のすべてのファイル(クラス・ファイルとJARファイルの両方)を示します。

CodeBaseフィールド(URL)は、省略可能なオプション・フィールドで、省略した場合は「任意のコード・ベース」が指定されます。

最初の署名者名フィールドは、署名者に関連付けられている1組の公開キー(キーストアの証明書内にある)に、別のメカニズムを通じてマッピングされた文字列の別名です。これらのキーは、ある署名付きのクラスが本当にこれらの署名者によって署名されたかどうかを確認するために使用されます。

この署名者フィールドは、複数の署名者の名前をカンマ区切りの文字列で指定できます。たとえば、Adam,Eve,Charlesは、AdamとEveとCharlesによって署名されることを意味します(各者の関係はORではなくAND)。

このフィールドは省略可能なオプション・フィールドで、省略した場合は「任意の署名者」、つまり「コードが署名付きかどうかは不問」の指定になります。

permissionエントリ内にある2つ目の署名者フィールドは、keystoreエントリの別名を表します。このkeystoreエントリには、そのアクセス権クラスを実装しているバイト・コードへの署名に使用される秘密キーに対応する公開キーが含まれます。このアクセス権エントリが有効なのは(つまりこのエントリに基づいてアクセス制御権が与えられるのは)、バイト・コードの実装が別名によって正しく署名されていることが確認された場合のみです。

プリンシパルの値はclass_nameとprincipal_nameのペアを指定します。このペアは、実行中のスレッドのプリンシパル・セット内にある必要があります。プリンシパル・セットは、Subjectによって実行するコードに関連付けられます。プリンシパル・フィールドは省略可能です。省略した場合は、「任意のプリンシパル」という意味になります。

CodeBaseフィールド、SignedByフィールド、およびPrincipalフィールドの順序は任意です。

次に示すのはポリシー・ファイル形式の非公式のBNF構文で、ここで小文字で始まる語はターミナルです:

PolicyFile -> PolicyEntry | PolicyEntry; PolicyFile
PolicyEntry -> grant {PermissionEntry}; |
           grant SignerEntry {PermissionEntry} |
           grant CodebaseEntry {PermissionEntry} |
           grant PrincipalEntry {PermissionEntry} |
           grant SignerEntry, CodebaseEntry {PermissionEntry} |
           grant CodebaseEntry, SignerEntry {PermissionEntry} |
           grant SignerEntry, PrincipalEntry {PermissionEntry} |
           grant PrincipalEntry, SignerEntry {PermissionEntry} |
           grant CodebaseEntry, PrincipalEntry {PermissionEntry} |
           grant PrincipalEntry, CodebaseEntry {PermissionEntry} |
           grant SignerEntry, CodebaseEntry, PrincipalEntry {PermissionEntry} |
           grant CodebaseEntry, SignerEntry, PrincipalEntry {PermissionEntry} |
           grant SignerEntry, PrincipalEntry, CodebaseEntry {PermissionEntry} |
           grant CodebaseEntry, PrincipalEntry, SignerEntry {PermissionEntry} |
           grant PrincipalEntry, CodebaseEntry, SignerEntry {PermissionEntry} |
           grant PrincipalEntry, SignerEntry, CodebaseEntry {PermissionEntry} |
           keystore "url"
SignerEntry -> signedby (a comma-separated list of strings)
CodebaseEntry -> codebase (a string representation of a URL)
PrincipalEntry -> OnePrincipal | OnePrincipal, PrincipalEntry
OnePrincipal -> principal [ principal_class_name ] "principal_name" (a principal)
PermissionEntry -> OnePermission | OnePermission PermissionEntry
OnePermission -> permission permission_class_name
                 [ "target_name" ] [, "action_list"]
                 [, SignerEntry];

ここで、いくつか例を示します。次のポリシーでは、Rolandによって署名されたコードにアクセス権a.b.Fooを与えます。

grant signedBy "Roland" {
    permission a.b.Foo;
};

次の例では、すべてのコード(署名者やCodeBaseにかかわらず)にFilePermissionを与えます。

grant {
    permission java.io.FilePermission ".tmp", "read";
};

次の例では、LiとRolandの両者によって署名されたコードに、2つのアクセス権を与えます。

grant signedBy "Roland,Li" {
    permission java.io.FilePermission "/tmp/*", "read";
    permission java.util.PropertyPermission "user.*";
};

次の例では、Liによって署名されhttp://example.comからロードされたコードに、2つのアクセス権を与えます。

grant codeBase "http://example.com/*", signedBy "Li" {
    permission java.io.FilePermission "/tmp/*", "read";
    permission java.io.SocketPermission "*", "connect";
};

次の例では、com.abc.TVPermissionを実装したバイト・コードが確実にLiによって署名されている場合にだけ、LiとRolandの両者によって署名されたコードに2つのアクセス権を与えます。

grant signedBy "Roland,Li" {
    permission java.io.FilePermission "/tmp/*", "read";
    permission com.abc.TVPermission "channel-5", "watch", 
        signedBy "Li";
};

2つ目の署名者フィールドを使用する目的は、インストールされたJava Runtimeにそのアクセス権クラスが存在しない場合に、不正行為を防ぐことです。たとえば、com.abc.TVPermissionクラスのコピーは、リモートのJARアーカイブの一部としてダウンロードできますが、ユーザー・ポリシーにそれを参照するエントリが含まれることがあります。アーカイブは短命なので、com.abc.TVPermissionクラスが別のWebサイトから再びダウンロードされる可能性があります。このときのユーザー・ポリシー内のアクセス権エントリの存在は、クラスのバイト・コードの最初のコピーに対するユーザーの信頼を反映するものであるため、2つ目のコピーが認証済であることは重要です。

認証を確実なものにするために、バイト・コードの最初のコピー(のハッシュ値)を保存して2つ目のコピーと比べる方法ではなく、デジタル署名を使用する理由は、アクセス権クラスの作者が合法的にクラス・ファイルを更新して新しい設計や実装を反映することがあるからです。

grant signedBy "Roland" {
    permission java.io.FilePermission "C:\\users\\Cathy\\*", "read";
};

"C:\users\Cathy\*"

最後に、プリンシパルベースのgrantエントリの例を示します。

grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
    permission java.io.FilePermission "/home/Alice", "read, write";
};

これにより、X500Principalのcn=Aliceとして実行するコードには/home/Aliceの読取りと書込みのアクセス権が与えられます。

次の例は、codesource情報とprincipal情報を持つgrant文を表しています。

grant codebase "http://www.games.example.com",
      signedBy "Duke",
      principal javax.security.auth.x500.X500Principal "cn=Alice" {
    permission java.io.FilePermission "/tmp/games", "read, write";
};

これにより、Dukeによって署名され、www.games.example.comからダウンロードされたコードがcn=Aliceによって実行されると、/tmp/gamesディレクトリの読取りと書込みのアクセス権が与えられます。

次の例は、キーストアの別名を置き換えるgrant文を示しています。

keystore "http://foo.bar.example.com/blah/.keystore";

grant principal "alice" {
    permission java.io.FilePermission "/tmp/games", "read, write";
};

aliceは、javax.security.auth.x500.X500Principal cn=Aliceに置き換えられます。ただし、キーストアの別名aliceに関連付けられたX.509証明書がサブジェクトの識別名cn=Aliceを持っていることが前提となります。これにより、X500Principalのcn=Aliceによって実行されるコードには、/tmp/gamesディレクトリへの読取りと書込みのアクセス権が与えられます。

ポリシー・ファイルとセキュリティ・プロパティ・ファイルでは、プロパティの展開が可能です。プロパティの展開は、シェルでの変数の展開に似ています。つまり、ポリシー・ファイルまたはセキュリティ・プロパティ・ファイルに${some.property}などの文字列が出現すると、それは指定されたシステム・プロパティの値まで展開されます。たとえば、

permission java.io.FilePermission "${user.home}", "read";

${user.home}は、システム・プロパティuser.homeの値に展開されます。そのプロパティの値が/home/cathyの場合、上の例は次のようになります

permission java.io.FilePermission "/home/cathy", "read";

プラットフォームにより異なるポリシー・ファイルを使いやすくするために、${/}という特殊な表記(${file.separator}の簡略形)も使用できます。これは「${file.separator}」へのショートカットで、次のようにしてアクセス権を定義できます。

permission java.io.FilePermission "${user.home}${/}*", "read";

user.homeが/home/cathyで、使用しているのがLinuxであれば、上の例は次のように変換されます:

permission java.io.FilePermission "/home/cathy/*", "read";

また、user.homeがC:\users\cathyで、使用しているのがWindowsシステムであれば、上の例は次のように変換されます:

permission java.io.FilePermission "C:\users\cathy\*", "read";

特殊なケースとして、コード・ベースのプロパティを次のように記述すると、

grant codeBase "file:/${java.home}/lib/ext/"

file.separator文字は自動的にすべてスラッシュ(/)に置き換えられ、このことは、コード・ベースがURLであるため適切です。そのため、Windowsシステムでは、java.homeがC:\j2sdk1.2に設定されていても、上の例は次のように変換されます

grant codeBase "file:/C:/j2sdk1.2/lib/ext/"

したがって、コード・ベース文字列では${/}を使用する必要はありません(使用しないでください)。

プロパティの展開は、ポリシー・ファイル内で、二重引用符で囲まれた文字列が使用できる場所であればどこでも行われます。これには、signedby、codebase、ターゲット名、動作の各フィールドがあります。

プロパティの展開が許可されるかどうかは、セキュリティ・プロパティ・ファイルの"policy.expandProperties"プロパティの値によって決まります。このセキュリティ・プロパティの値がtrue (デフォルト)の場合は、展開が許可されます。

ノート: 入れ子のプロパティは使用できません。たとえば、

"${user.${foo}}"

この例では、fooプロパティがhomeに設定されている場合であっても、エラーになります。これは、プロパティ構文解析プログラムは入れ子になったプロパティを認識しないためです。プロパティ構文解析プログラムは、最初の${を見つけたら、次に最初の}を探し、結果の${user.$foo}をプロパティと解釈しようと試みます。しかし、そのようなプロパティがない場合はエラーになります。

ノート: grantエントリ、アクセス権エントリ、またはkeystoreエントリで展開できないプロパティがある場合、そのエントリは無視されます。たとえば、次のようにシステム・プロパティfooが定義されていない場合、

grant codeBase "${foo}" {
    permission ...;
    permission ...;
};

このgrantエントリ内のpermissionはすべて無視されます。また、次のような場合、

grant {
    permission Foo "${foo}";
    permission Bar;
};

permission Foo "${foo}";エントリだけが無視されます。また、次のように指定されている場合、

keystore "${foo}";

この場合は、keystoreエントリが無視されます。

ノート: Windowsシステムでは、文字列中で直接ファイル・パスを指定する場合は、単一のバックスラッシュは次のように二重のバックスラッシュで表します。

"C:\\users\\cathy\\foo.bat"

これは、文字列はトークナイザ(java.io.StreamTokenizer)によって処理され、トークナイザはバックスラッシュ(\)をエスケープ文字列と解釈するため(たとえば、\nは改行を表す)、バックスラッシュそのものを表すには、バックスラッシュを2つ重ねる必要があるからです。トークナイザが上の文字列の処理を終え、二重のバックスラッシュが単一のバックスラッシュに変換されると、結果は次のようになります

"C:\users\cathy\foo.bat"

文字列中のプロパティの展開は、トークナイザがその文字列の処理を完了したあとに行われます。たとえば、次のような文字列があるとします。

"${user.home}\\foo.bat"

トークナイザは、この文字列中の二重のバックスラッシュを単一のバックスラッシュに変換し、結果は次のようになります。

"${user.home}\foo.bat"

次に、${user.home}プロパティが展開されて次のようになります。

"C:\users\cathy\foo.bat"

ここでは、user.homeの値をC:\users\cathyとしています。もちろん、プラットフォームに依存しないために、明示的にスラッシュを使うのではなく、${/}プロパティを使って次のように指定する方が望ましいと言えます。

"${user.home}${/}foo.bat"

ポリシー・ファイルでは一般化された形式の展開もサポートされています。たとえば、アクセス権名に${{protocol:protocol_data}}という形式の文字列が含まれているとします。このような文字列がアクセス権名に含まれている場合、protocolの値で実行される展開のタイプが決まり、protocol_dataを使用して展開が実行されます。protocol_dataは空にすることも可能で、その場合、上の文字列は次のような形式になります:

${{protocol}}

デフォルトのポリシー・ファイルの実装では、次の2つのプロトコルがサポートされます。

1. ${{self}}

   プロトコルselfは、${{self}}文字列全体を1つ以上のプリンシパル・クラスとプリンシパル名のペアに置き換えることを示します。実際に実行される置換えは、permissionを含むgrant節の内容によって決まります。

   grant節にプリンシパルの情報が含まれていない場合は、permissionは無視されます。プリンシパルベースのgrant節のコンテキストでは、ターゲット名に${{self}}を含むpermissionのみが有効です。たとえば、次のgrant節内のBarPermissionは常に無視されます。

   grant codebase "www.foo.example.com", signedby "duke" {
       permission BarPermission "... ${{self}} ...";
   };

   grant句にプリンシパル情報が含まれている場合は、${{self}}がそのプリンシパル情報に置き換えられます。たとえば、次のgrant節のBarPermission内の${{self}}は、javax.security.auth.x500.X500Principal "cn=Duke"に置き換えられます。

   grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
       permission BarPermission "... ${{self}} ...";
   };

   grant句内にカンマで区切られたプリンシパルのリストがある場合、${{self}}は、そのカンマで区切られたプリンシパルのリストに置き換えられます。grant句内のプリンシパル・クラスとプリンシパル名がどちらもワイルドカードになっている場合、${{self}}は、現在のAccessControlContext内のSubjectに関連付けられたすべてのプリンシパルに置き換えられます。

   次の例は、selfとキーストアの別名の置き換えの両方を含む例を示しています。

       keystore "http://foo.bar.example.com/blah/.keystore";
   
       grant principal "duke" {
           permission BarPermission "... ${{self}} ...";
       };

   上の例では、初めにdukeが、javax.security.auth.x500.X500Principal "cn=Duke"に展開されますが、KeyStoreの別名"duke"に関連付けられたX.509証明書に、サブジェクトの識別名"cn=Duke"があることが前提となります。次に、${{self}}が、grant節内で展開されたその同じプリンシパル情報に置き換えられます。javax.security.auth.x500.X500Principal "cn=Duke"。

2. ${{alias:alias_name}}

   プロトコルaliasは、java.security.KeyStore別名の置換を示します。使用されるKeyStoreは、KeyStoreエントリに指定されたものです。Policyのファイル形式を参照してください。alias_nameは、KeyStoreの別名を表します。${{alias:alias_name}}は、javax.security.auth.x500.X500Principal "DN"に置き換えられます。このDNは、alias_nameに属する証明書のサブジェクト識別名を表します。たとえば:

               keystore "http://foo.bar.example.com/blah/.keystore";
   
               grant codebase "www.foo.example.com" {
                   permission BarPermission "... ${{alias:duke}} ...";
               };

   上の例の別名dukeに関連付けられているX.509証明書は、KeyStore (foo.bar.example.com/blah/.keystore)から取得されます。dukeの証明書がサブジェクト識別名として"o=dukeOrg, cn=duke"を指定し、${{alias:duke}}がjavax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke"で置き換えられるものとします。

   次のエラー条件に該当する場合、アクセス権エントリは無視されます。

   • keystoreエントリが指定されていない
   • alias_nameが指定されていない
   • alias_nameの証明書を取得できない
   • 取得される証明書がX.509証明書ではない

プリンシパルが特定のCodeSourceからクラスを実行するとき、セキュリティ・メカニズムはポリシー・オブジェクトを調べてどのアクセス権を与えるかを決定します。この決定は、VMにインストールされたPolicyオブジェクトのgetPermissionsメソッドまたはimpliesメソッドを呼び出すことにより行われます。

ワイルドカード(*)の使用が認められているなどの理由により、ProtectionDomain内のコード・ソースがポリシー内の複数のエントリのコード・ソースに一致することがあります。

ポリシー内の適切なアクセス権セットを探すために、次のアルゴリズムが使用されます。

1. コードが署名されている場合は、公開キーと照合します。

2. ポリシーによって認識されないキーは無視します。

   すべてのキーが無視された場合は、コードを未署名として処理します。

3. キーが一致している、または署名者が指定されていない場合は、キーのポリシー内のすべてのURLとの照合を試行します。

4. キーが一致した(または署名者が指定されていない)場合、およびURLが一致した(またはコード・ベースが指定されていない)場合は、ポリシー内のすべてのプリンシパルを、現在実行中のスレッドに関連付けられているプリンシパルと照合しようとします。

5. キー、URLまたはプリンシパルのいずれも一致しない場合は、デフォルトの組込みアクセス権(オリジナルのサンドボックス・アクセス権)を使用します。

ポリシー・エントリのcodeBase URLの正確な意味は、最後の文字に依存します。末尾が/のcodeBaseは、指定されたディレクトリ内のすべてのクラス・ファイル(JARファイルを除く)を示します。末尾が/*のcodeBaseは、そのディレクトリ内にあるすべてのファイル(クラス・ファイルとJARファイルの両方)を示します。末尾が/-のcodeBaseは、指定されたディレクトリとその下の全サブディレクトリ内のすべてのファイル(クラス・ファイルとJARファイルの両方)を示します。

たとえば、ポリシー内に"http://example.com/-"がある場合は、そのWebサイト上のすべてのコード・ベースはこのポリシー・エントリに一致します。一致するコード・ベースには、"http://example.com/j2se/sdk/"および"http://example.com/people/gong/appl.jar"があります。

複数のエントリが一致する場合は、それらのエントリ内のすべてのアクセス権が与えられます。つまり、アクセス権は追加割当てできます。たとえば、キーAで署名されたコードにアクセス権Xが与えられ、キーBで署名されたコードにはアクセス権Yが与えられており、特定のコード・ベースが指定されていない場合、AとBの両方で署名されたコードにはアクセス権XとYの両方が与えられます。同様に、codeBaseが"http://example.com/-"のコードにアクセス権Xが与えられ、"http://example.com/people/*"のコードにアクセス権Yが与えられており、特定の署名者が指定されていない場合は、"http://example.com/people/applet.jar"からのアプレットにはXとYの両方のアクセス権が与えられます。

ここでのURLのマッチングは、純粋に構文上のマッチングです。たとえば、あるポリシーにURL "ftp://ftp.example.com"を指定するエントリがあるとします。このようなエントリは、Javaコードを直接ftpからダウンロードして実行できる場合にだけ有用です。

ローカル・ファイル・システムのURLを指定する場合、ファイルのURLを使用できます。たとえばLinuxの/home/cathy/tempディレクトリ内のファイルを指定するには、次のようにします

"file:/home/cathy/temp/*"

WindowsのCドライブにあるtempディレクトリ内のファイルを指定するには、次のようにします

"file:/c:/temp/*"

ノート: codeBaseのURLには、プラットフォームに関係なく、常に(バックスラッシュではなく)スラッシュを使用します。

次のような、絶対パスを使用することもできます。

"/home/gong/bin/MyWonderfulJava"

Policyのリファレンス実装では、1つまたは複数のポリシー構成ファイルからポリシーを指定できます。構成ファイルは、特定のコード・ソースからのコードに許可されるアクセス権を指定します。ポリシー・ファイルは、単純なテキスト・エディタを使用して作成できます。デフォルトでは、システム全体のポリシー・ファイルが1つあり、ユーザー・ポリシー・ファイルが1つあります。システム・ポリシー・ファイルは、デフォルトでは次の場所にあります。

• {java.home}/conf/security/java.policy (Linux and macOS)
• {java.home}\conf\security\java.policy (Windows)

ここで、java.homeはJDKがインストールされているディレクトリを示すシステム・プロパティです。ユーザー・ポリシー・ファイルは、デフォルトでは次の場所にあります。

• {user.home}/.java.policy (LinuxおよびmacOS)
• {user.home}\.java.policy (Windows)

ここでuser.homeは、ユーザーのホーム・ディレクトリを示すシステム・プロパティです。

Policyが初期化されると、まずシステム・ポリシーがロードされ、次に、ロードされたシステム・ポリシーにユーザー・ポリシーが追加されます。どちらのポリシーも存在しない場合は、組込みポリシーが使われます。組込みポリシーは、オリジナルのサンドボックス(sandbox)ポリシーと同じものです。ポリシー・ファイルの場所は、セキュリティ・プロパティ・ファイルの中で指定されています。セキュリティ・プロパティ・ファイルは、次の場所にあります。

• {java.home}/conf/security/java.security (LinuxおよびmacOS)
• {java.home}\conf\security\java.security (Windows)

ポリシー・ファイルの場所は、次のような形式の名前を持つプロパティの値として指定されています。

policy.url.n

ここで、nは数値です。次に示す形式の行で、それぞれのプロパティの値を指定します。

policy.url.n=URL

ここで、URLはURLの指定を表します。たとえば、デフォルトのシステムおよびユーザー・ポリシー・ファイルは、セキュリティ・プロパティ・ファイルに次のように指定されています。

policy.url.1=file:${java.home}/conf/security/java.policy
policy.url.2=file:${user.home}/.java.policy

「http://」の形式のものも含めて、実際には複数のURLを指定でき、指定したポリシー・ファイルのすべてがロードされます。また、上に示したポリシー・ファイルの指定のうち、2番目のポリシー・ファイルの指定をコメント・アウトするか、あるいは修正すれば、デフォルト・ユーザー・ポリシー・ファイルの読込みを無効にすることができます。

アルゴリズムは、policy.url.1から処理を開始して、番号を1つずつ増やしながら、URLが見つからなくなるまで処理を続けます。したがって、policy.url.1とpolicy.url.3がある場合、policy.url.3は読み込まれません。

アプリケーションを実行するときに、追加のポリシー・ファイルや別のポリシー・ファイルを指定することもできます。この場合は、-Djava.security.policyコマンド行引数を使用してjava.security.policyプロパティの値を設定します。たとえば、次の例を考えてみます。

java -Djava.security.manager -Djava.security.policy=pURL SomeApp

ここでpURLは、ポリシー・ファイルの位置を示すURLです。指定されたポリシー・ファイルは、セキュリティ・プロパティ・ファイルで指定されたすべてのポリシー・ファイルに追加されてロードされます。-Djava.security.manager引数により、デフォルトのセキュリティ・マネージャが確実にインストールされるので、アプレットおよびアプリケーションの管理の説明にあるように、アプリケーションはポリシー・チェックを受けます。アプリケーションSomeAppがセキュリティ・マネージャをインストールする場合は、これは必要はありません。

次のように、二重の等号(==)の付いた形式を使用すると、指定されたポリシー・ファイルだけが使用され、その他のポリシー・ファイルはすべて無視されます。

java -Djava.security.manager -Djava.security.policy==pURL SomeApp

Policyクラスの現在の設計は、すべての場合に適用できる包括的なものではありません。その点については考察が重ねられ、多くの場合に適したメソッドの呼出しが確実にできるよう部分的な改良が進められています。それまでの間、デフォルトのポリシー・クラスを別のポリシー・クラスに置き替えることができます。ただし、置き換えるポリシー・クラスが抽象Policyのサブクラスであり、getPermissionsメソッド(および必要に応じて他のメソッド)を実装していることが条件です。

Policyのリファレンス実装は、policy.providerセキュリティ・プロパティ(セキュリティ・プロパティ・ファイル、<java-home>/conf/security/java.security内)の値を、目的のPolicy実装クラスの完全修飾形の名前に設定しなおすことにより変更できます。

セキュリティ・プロパティpolicy.providerは、ポリシー・クラスの名前を指します。デフォルトは次のとおりです。

policy.provider=sun.security.provider.PolicyFile

カスタマイズするには、次のように、このプロパティに別のクラスを指定します。

policy.provider=com.mycom.MyPolicy

MyPolicyクラスは、java.security.Policyのサブクラスでなければなりません。このような、ポリシー・クラスのオーバーライドはあくまでも一時的な解決策であり、より包括的なポリシーAPIが設計されれば不要になります。

図1-11に示すように、呼出し元が複数ある計算スレッドで、アクセス制御のチェックを行うとします(保護ドメインの境界を越える、複数のメソッド呼出しと考えてください)。

図1-11 保護ドメインの境界を超える複数のメソッド呼出し

「図1-11 保護ドメインの境界を超える複数のメソッド呼出し」の説明

AccessControllerのcheckPermissionメソッドが直前の呼出し元(Fileクラスのメソッドなど)によって呼び出されたとき、要求されたアクセスを許可するか拒否するかを判断する基本のアルゴリズムは次のとおりです。

呼出しチェーンの中に、要求されたアクセス権を持たない呼出し元がある場合は、AccessControlExceptionがスローされます。ただし、ある呼出し元のドメインにそのアクセス権が与えられており、その呼出し元に「特権付き(privileged)」のマークが付けられていて(次の項を参照)、それ以後その呼出し元から(直接または間接的に)呼び出されるすべての関係者がそのアクセス権を持つ場合は例外です。

2つの実装手法があります。

• 「積極的評価」を行う実装では、スレッドが新しい保護ドメインに入るときと出るときには必ず、一組の有効なアクセス権が動的に更新される。

  この方法の長所は、アクセスが許可されているかどうかのチェックが容易になり、多くの場合、迅速になるという点です。短所は、ドメインの境界を越えた呼出しの頻度よりもアクセス権のチェックの頻度の方がかなり少なくなるために、アクセス権の更新のかなりの部分が無駄な行為になる可能性があるという点です。

• 「消極的評価」を行う実装では、アクセス権のチェックが要求されたときにスレッドの状態(現在の状態を反映し、それには現在のスレッドのスタックまたはそれに相当するものが含まれる)が調べられ、要求された特定のアクセスを許可するかどうかが決定される。

  このアプローチの可能性のある短所の1つに、アクセス権のチェック時のパフォーマンスの低下があります。ただし、この低下は「積極的評価」アプローチでも発生する可能性があります(初期に、ドメイン間の各呼出しに拡散されますが)。私たちが行った実装では、良好なパフォーマンスが達成されました。全般的に、消極的評価の方法が経済的だと考えます。

したがって、アクセス権のチェックのアルゴリズムは、現在は「消極的評価」で実装されています。現在のスレッドが呼出し元1、呼出し元2、呼出し元mの順で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);

AccessControllerクラスの新しいstaticメソッドにより、クラス・インスタンス内のコードはAccessControllerにそのコードの本体が「特権付きである」ことを通知できます。特権付きの場合、そのコードの本体は、アクセスの要求の発生元のコードが何であるかには関係なく、使用可能なリソースへのアクセスを要求する責任のみを負います。

つまり、ある呼出し元がdoPrivilegedメソッドを呼び出すと、その呼出し元には「特権付き」のマークが付けられます。アクセス制御を決定する場合、checkPermissionメソッドは、コンテキスト引数のないdoPrivilegedの呼出しによって「特権付き」のマークが付けられた呼出し側に届いたときに、チェックを中止します(コンテキスト引数については次のセクションを参照)。その呼出し元のドメインが指定されたアクセス権を持っている場合は、checkPermissionはそれ以上のチェックを行わずに正常復帰し、要求されたアクセスが許可されていることを示します。そのドメインが指定されたアクセス権を持たない場合は、通常は例外が発行されます。

「特権付き」機能の通常の使用法は、次のとおりです。

「特権付き」ブロックからの戻り値が必要ない場合は、次のようにします。

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

PrivilegedActionは、Objectを返すrunという単一のメソッドを持つインタフェースです。これは、そのインタフェースを実装する匿名の内部クラスを作成する例で、runメソッドの実装を具体的に示しています。doPrivilegedへの呼出し時に、PrivilegedActionの実装のインスタンスが渡されます。doPrivilegedメソッドは、特権を有効にした後で、PrivilegedActionの実装からrunメソッドを呼び出し、runメソッドの戻り値をdoPrivilegedの戻り値として返します(これは、上の例では無視されています)。内部クラスの詳細は、Javaチュートリアルのネストされたクラスを参照してください。

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

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

runメソッド内の動作で「チェック終了」例外(メソッドのthrows節の中に記述される)をスローする場合は、PrivilegedActionインタフェースではなくPrivilegedExceptionActionインタフェースを使用する必要があります。

  somemethod() throws FileNotFoundException {
       ...normal code here...
     try {
       FileInputStream fis = (FileInputStream)
        AccessController.doPrivileged(
         new PrivilegedExceptionAction() {
           public Object 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
       // <code>PrivilegedActionException</code>.
       throw (FileNotFoundException) e.getException();
     }
       ...normal code here...
 }

特権付きにはいくつか重要な点があります。まず、この概念は単一スレッドの内部でだけ存在します。特権付きのコードが終了すると、その特権は確実に消去または失効します。

次に、この例では、runメソッド内のコード本体は特権付きです。しかし、これが権限の少ない信頼性の低いコードを呼び出した場合、そのコードは結果として何の権限も得られません。アクセス権は、特権付きのコードがそのアクセス権を持つ場合にのみ与えられ、checkPermission呼出しに至るまでの呼出しチェーン内のこれ以降のすべての呼出し元も同様になります。

他のアクセス権をチェックするためのスタックの完全なトラバースを禁止せずにコード内でコードの特権のサブセットを表明できるAccessController.doPrivilegedのバリアントを使用できます。特権のサブセットのアサーションを参照してください。

コードを「特権付き」としてマーキングする方法の詳細は、付録A: 特権ブロックのためのAPIを参照してください。

keytoolは、キーと証明書を管理するためのユーティリティです。それにより、自己認証(他のユーザーまたはサービスに対して、ユーザーが自分自身を認証する)やデータの整合性とデジタル署名を使用した認証サービスで使用するための独自の公開キーと秘密キーのペアおよび関連証明書を管理できます。認証情報には、X.509証明書のシーケンス(チェーン)と、関連の秘密キー(いわゆる「別名」によって参照可能)の両方が含まれます。このツールは、証明書(ユーザーにより「信頼されている」)も管理します。証明書は、認証情報と同じデータベースに格納され、「別名」によって参照できます。

keytoolは、キーと証明書をキーストアに格納します。デフォルトのキーストア実装は、キーストアをファイルとして実装します。キーストアは、秘密キーをパスワードで保護します。

X.509証明書のチェーンは、証明書発行局(CA)という組織によって提供されます。アイデンティティ(CAを含む)は、その秘密キーを使用して、オブジェクト(SSLを使用してセキュリティ設定したチャネルなど)との関係、署名したコードのアーカイブとの関係、および発行したX.509証明書(CA用)との関係を認証します。ブートストラップ・ツールとして、-gencertオプションを使用して生成した証明書は、証明書発行局が証明書チェーンを返すまで使用される可能性があります。

このデータベース内の秘密キーは、不適切に公開されないように常に暗号化されて保存されます。データベースにアクセスするか、データベースを変更する場合には、パスワードが要求されます。これらの秘密キーは、複数の単語で構成される「パスワード」を使用して暗号化されます。パスワードを忘れた場合、認証キーを復元することはできません。

実際、キーストア内の各秘密キーは、個々のパスワードによって保護することができます。このパスワードは、キーストアの全体的な整合性を保護するパスワードと同じである場合も、異なる場合もあります。

現在、このツールは、コマンド行でシェル・プロンプトに、単にkeytoolと入力して使用するようになっています。keytoolは、適切なJavaクラスを実行するスクリプトでSDKに組み込まれています。

各コマンドのコマンド行オプションは、任意の順序で指定できます。不正確なオプションを入力したり、keytool -helpと入力すると、ツールの使用方法の概略が出力デバイス(シェル・ウィンドウなど)に出力されます。

ラムダ式または匿名の内部クラスを使う場合は、アクセスするローカル変数がすべてfinalまたは事実上のfinalである必要があります。

String lib = "awt";
AccessController.doPrivileged((PrivilegedAction<Void>)
    () -> {
        System.loadLibrary(lib);
        return null; // nothing to return
    }
); 
   
AccessController.doPrivileged(new PrivilegedAction<Void>() {
    public Object run() {
        System.loadLibrary(lib);
        return null; // nothing to return
    }        
});

lib = "swing";

String lib;
    
// The lib variable gets set multiple times so you can't make it
// effectively final.
  
// Create a final String that you can use inside of the run method
final String fLib = lib;
    
AccessController.doPrivileged((PrivilegedAction<Void>)
    () -> {
        System.loadLibrary(fLib);
        return null; // nothing to return
    }
);

runメソッド内で実行された処理によってチェック例外(メソッドのthrows節にリストする必要がある例外)がスローされた場合は、PrivilegedActionインタフェースではなく、PrivilegedExceptionActionインタフェースを使用する必要があります。

public void processSomefile() throws IOException {

    try {
        Path path = FileSystems.getDefault().getPath("somefile");
        BufferedReader br = AccessController.doPrivileged(
            (PrivilegedExceptionAction<BufferedReader>)
                () -> Files.newBufferedReader(path)
        );
        // ... read from file and do something
    } catch (PrivilegedActionException e) {
    
        // e.getException() should be an instance of IOException
        // as only checked exceptions will be wrapped in a
        // PrivilegedActionException.
        throw (IOException) e.getException();
    }
}

doPrivilegedメソッドの典型的な使用例は、現在のメソッドの呼出し側に必要なすべてのアクセス権がなくても、これを呼び出すことで、そのメソッドでアクセス権のチェックを必要とする1つ以上のアクションを実行できるようにする場合です。

現在のメソッドをコーディングするときには、アクションを実行するために呼出し側のメソッドのアクセス権を一時的に拡張できます。