Java 2 セキュリティー・ポリシー・ファイル
Java™ 2 Platform, Enterprise Edition (J2EE) バージョン 1.3 およびそれ以降の仕様には、コンテナー・プロバイダーとアプリケーション・コード間の責任について、 明確に定義されたプログラミング・モデルが備わっています。 このプログラミング・モデルを実行するには、Java 2 セキュリティー・マネージャーの使用をお勧めします。 一部のオペレーションは、アプリケーション・コードではサポートされていません。 これは、そのようなオペレーションが、コンテナーの振る舞いと操作を妨げるためです。 Java 2 セキュリティー・マネージャーは、 コンテナーとアプリケーション・コードの責任を実行するために製品で使用されます。

この製品は、ポリシー・ファイル管理をサポートしています。 この製品にある多数のポリシー・ファイルは、静的であるか動的であるかのいずれかです。 動的ポリシー は、特定のリソース・タイプに対するアクセス権のテンプレートです。 動的ポリシー・テンプレートには、相対コード・ベースが定義されていません。 コード・ベースは、デプロイメントおよびランタイム・データから動的に算出されます。
静的ポリシー・ファイル
ポリシー・ファイル | ロケーション |
---|---|
java.policy |
|
server.policy | profile_root/properties/server.policy。 デフォルトの許可は、すべての製品サーバーに付与されます。 |
client.policy | profile_root/properties/client.policy。 デフォルトの許可は、ノード上のすべての製品クライアント・コンテナーおよびアプレットに付与されます。 |
動的ポリシー・ファイル
ポリシー・ファイル | ロケーション |
---|---|
spi.policy | profile_root/config/cells/cell_name このテンプレートは、サービス・プロバイダー・インターフェース (SPI)、 または製品に組み込まれているサード・パーティー製リソースのためのものです。 SPI の例には、MQ Series の Java Message Service (JMS) および Java Database Connectivity (JDBC) ドライバーがあります。組み込みリソースのコード・ベースは、 構成 (resources.xml ファイル) およびランタイム・データから動的に決定され、 spi.policy ファイルで定義されている許可は、自動的にこれらのリソースおよびリソース・アダプターのクラスパスで指定された JAR ファイルに適用されます。 spi.policy ファイルのデフォルト許可は、java.security.AllPermissions です。 |
library.policy | profile_root/config/cells/cell_name/nodes このテンプレートは、ライブラリー (Java ライブラリー・クラス) 用です。 共有ライブラリーは、複数の製品アプリケーションで使用するように定義できます。 library.policy ファイルのデフォルトの許可は空 です。 |
app.policy | profile_root/config/cells/cell_name app.policy ファイルは、
cell_name 内の node_name で実行されるすべてのエンタープライズ・アプリケーションに付与される、デフォルトの許可を定義します。
注: app.policy ファイルへの更新は、app.policy ファイルが属するノード上のエンタープライズ・アプリケーションのみに適用されます。
|
was.policy | profile_root/config/cells/cell_name このテンプレートは、アプリケーション固有の許可のためのものです。 was.policy は、エンタープライズ・アーカイブ (EAR) ファイルに組み込まれています。 |
ra.xml | rar_file_name/META-INF/was.policy.RAR。
このファイルには、ra.xml ファイルで定義された、許可の仕様を含めることができます。ra.xml ファイルは、RAR ファイルに組み込まれています。 |
ポリシー・ファイルの構文
grant [codebase <Codebase>] {
permission <Permission>;
permission <Permission>;
permission <Permission>;
};
<CodeBase>: A URL.
For example, "file:${java.home}/lib/tools.jar"
When [codebase <Codebase>] is not specified, listed
permissions are applied to everything.
If URL ends with a JAR file name, only the classes in the JAR file belong to the codebase. If URL ends with "/", only the class files in the specified
directory belong to the codebase. If URL ends with "*", all JAR and class files in the specified
directory belong to the codebase. If URL ends with "-", all JAR and class files in the specified
directory and its subdirectories belong to the codebase.
<Permissions>: Consists from
Permission Type : class name of the permission
Target Name : name specifying the target
Actions : actions allowed on target
以下に例を示します。
java.io.FilePermission "/tmp/xxx", "read,write"
各許可の詳細については、デベロッパー・キットの仕様を参照してください。動的ポリシーの構文
エンタープライズ・アプリケーションの動的ポリシー・ファイルで、特定タイプのリソース用の許可を定義することができます。 このアクションは、製品の予約シンボル を使用して実現されます。 予約シンボルの有効範囲は、それが定義される場所によって異なります。 app.policy ファイルで許可を定義する場合、このシンボルは、 node_name で実行されるすべてのエンタープライズ・アプリケーションのすべてのリソースに適用されます。 META-INF/was.policy ファイルで許可を定義する場合、シンボルは、特定のエンタープライズ・アプリケーションにのみ適用されます。 以下の表に、コード・ベースで有効なシンボルがリストされています。シンボル | 意味 |
---|---|
file:${application} | アクセス権は、アプリケーション内のすべてのリソースに適用されます。 |
file:${jars} | アクセス権は、アプリケーション内のすべてのユーティリティー Java アーカイブ (JAR) ファイルに適用されます。 |
file:${ejbComponent} | アクセス権は、アプリケーション内の Enterprise JavaBeans (EJB) リソースに適用されます。 |
file:${webComponent} | アクセス権は、アプリケーション内の Web リソースに適用されます。 |
file:${connectorComponent} | アクセス権は、アプリケーション内のコネクター・リソースに適用されます。 |
grant codeBase "file:DefaultWebApplication.war" {
permission java.security.SecurityPermission "printIdentity";
};
grant codeBase "file:IncCMP11.jar" {
permission java.io.FilePermission
"${user.install.root}${/}bin${/}DefaultDB${/}-",
"read,write,delete";
};
シンボル | 意味 |
---|---|
file:${application} | アクセス権は、アプリケーション内のすべてのリソースに適用されます。 |
file:${jars} | アクセス権は、アプリケーション内のすべてのユーティリティー JAR ファイルに適用されます。 |
file:${ejbComponent} | アクセス権は、アプリケーション内のエンタープライズ Bean リソースに適用されます。 |
file:${webComponent} | アクセス権は、アプリケーション内の Web リソースに適用されます。 |
file:${connectorComponent} | アクセス権は、アプリケーション内およびスタンドアロンのコネクター・リソース内の両方のコネクター・リソースに適用されます。 |
シンボル | 意味 |
---|---|
${app.installed.path} | アプリケーションがインストールされているパス |
${was.module.path} | モジュールがインストールされているパス |
${current.cell.name} | 現在のセル名 |
${current.node.name} | 現在のノード名 |
${current.server.name} | 現在のサーバー名 |
新しい許可をどこに追加するかは、慎重に検討する必要があります。 許可の指定を間違えると、AccessControlException 例外が起こります。動的ポリシーは実行時にコード・ベースを解決するため、 問題が生じているポリシー・ファイルを特定するのは困難です。 許可は、必要なリソースだけに追加してください。 例えば、可能ならば、${application} ではなく ${ejbcomponent}、etc を使用し、 app.policy ファイルではなく was.policy ファイルを更新します。
静的ポリシー・フィルター操作
静的ポリシーのフィルター操作のサポートは、ある程度限定されています。 app.policy ファイルおよび was.policy ファイルに、thefilterMask キーワードで filter.policy ファイルに定義された許可がある場合、ランタイムはアプリケーションから許可を除去し、ログに監査メッセージが記録されます。 ただし、app.policy および was.policy ファイルで定義された許可が複合許可 (例えば java.security.AllPermission) である場合、許可は除去されませんが、警告メッセージがログ・ファイルに書き込まれます。ポリシーのフィルター操作は Developer Kit の許可のみをサポートします。許可のパッケージ名は java または javax で始まります。
ランタイム・ポリシーのフィルター操作サポートは、 より強力なフィルター操作を提供するために用意されているものです。 app.policy ファイルおよび was.policy ファイルに、runtimeFilterMask キーワードで filter.policy ファイルに定義された許可がある場合、 アプリケーションにどのような許可が付与されていても、ランタイムはアプリケーションからその許可を除去します。 例えば、モジュールの 1 つに付与されている java.security.AllPermission 許可が was.policy ファイルにある場合でも、runtimeFilterMask などの指定された許可は、実行時に付与された許可から除去されます。
ポリシー・ファイルの編集
Developer Kit によって提供されるポリシー・ツール (app_server_root/java/jre/bin/policytool) を使用して、 それまでのポリシー・ファイルを編集することをお勧めします。WebSphere Application Server Network Deployment の場合は、編集前にポリシー・ファイルをリポジトリーから抽出してください。 ポリシー・ファイルの抽出後は、 ポリシー・ツールを使用してファイルを編集します。 変更したポリシー・ファイルはリポジトリーに入れ、他のノードと同期させる必要があります。
トラブルシューティング
- トレース (RAS トレースにより構成)。次のトレース指定によってトレースを使用可能にします。
重要: 下記のコマンドは、連続した 1 行となります。
com.ibm.ws.security.policy.*=all=enabled: com.ibm.ws.security.core.SecurityManager=all=enabled
- トレース (プロパティーにより構成)。Java の java.security.debug プロパティーを指定します。
java.security.debug プロパティーの有効な値は次のとおりです。
- Access。必要な許可、コード、スタック、およびコード・ベースの場所など、 すべてのデバッグ情報を出力します。
- Stack。デバッグ情報 (必要な許可、コード、スタックなど) を印刷します。
- Failure。必要な許可やコードなどのデバッグ情報を出力します。
- ffdc。ffdc を使用可能にするには、Level=4 および LAE=true を変更して、ffdcRun.properties ファイルを変更します。 ログ・ファイルで、Access Violation キーワードを探してください。