|
JAVA Developer 2003年10月号より転載
それでは、実際に図3のWebアプリケーションであるmyappに、ポリシーを設定する例を見てみましょう。
●grantエントリ
grantエントリのテンプレートとしてリスト3を用意して、Tomcatのcatalina.policyに適宜追加してください。grantエントリは順序に依存しませんので、テキストエディタでCATALINA_HOME/conf/catalina.policyを開いて、ほかのgrantエントリの中でない場所に記述します。
|
リスト3 簡単なgrantエントリの例
|
grant codeBase "file:///c:/myapp/-"
{
permission java.io.FilePermission
"c:${/}myapp${/}data${/}-",
"read,write";
};
|
ここでは、コードベースとして与えるURLに注目してください。Windowsプラットフォームの場合はドライブ名を含める場合、このように記述します。「file:」のあとにスラッシュを3つ続けない表記もありますが、筆者は通例こうしています。URLですので「￥」記号を使わないように注意してください。
また、URLでありながら拡張されていて、FilePermissionのターゲットと同様のワイルドカードが利用できます。つまり、この例のように「/-」で終わっていれば、そのディレクトリ以下の全ディレクトリの全ファイルを意味します。
このとき、「file:///c:/myapp/WEB-INF/-」としなかったのは、JSPファイルを含めるためです。Tomcatのしくみをご存じの方なら、JSPはCATALINA_HOME/work/以下のサブディレクトリでクラスファイルへとコンパイルされることに気付くはずです。
しかし、この場合、コードベースはCATALINA_HOME/work/に置いても動作しません。c:/myapp/ディレクトリにあるJSPファイルは、コードベースも「file:///c:/myapp/」とするようになっています。
●パーミッションエントリ
パーミッションエントリの記述として、ファイルへの読み書き権を付与しています。おそらくデータファイルかなにかがあるのでしょう。しかし、コードベースではファイルシステムのURLを記述し、パーミッションでは「c:${/}」となっています。この設定はほかのUNIX環境に移動させるときには記述し直す必要があります（移動させるとして）。そうでないにしても、非常に気になるイヤな表記になっています。
・プロパティの利用
ここでは、プロパティ展開を使ってすっきりさせることができます。プロパティはJavaコマンドの起動時などによく使っている、「-Djava.security.policy=……」のようなものですね。
次のようにして起動したプログラムでは、「prop.value」というプロパティが設定されています。
> java -Dprop.value=JAVADEVE
|
先に、ポリシーファイルではプロパティの展開が利用できると書きました。ポリシーファイルではこのプロパティに${prop.value}とすれば展開できます。ということは、Tomcat起動スクリプトはOS依存ですので、そのOS依存部に記述してしまえば、それ以外の設定ファイルなどは共通化できそうです。
・Tomcatにおけるプロパティの設定
それでは、Tomcat起動時に独自プロパティを追加する方法を説明しましょう。Tomcatは通常startupなどのスクリプトコマンドで起動します。startupコマンドに「-Dprop.value=……」などのコマンドライン引数をつけても認識してくれません。
しかし、Tomcatの起動スクリプトは、その起動プロセス中に、ユーザー独自のプロパティを追加させるしくみがあります。環境変数CATALINA_OPTSと、起動スクリプトsetenvを組み合わせて実現します。
環境変数CATALINA_OPTSは、Tomcat起動時にjavaコマンドに与えるコマンドラインオプションを追加するための環境変数です。また、setenvスクリプト（UNIX環境ではsetenv.sh、Windows環境ではsetenv.bat）は、Tomcatの起動スクリプトがその存在をチェックし、もし存在すれば呼び出してくれるフック用スクリプトファイルです。デフォルトインストール時には存在しません。
これらのしくみを使って、前述のOS依存になってしまったポリシーファイルを統一してみます。
リスト4、5のような簡単なスクリプトを作ってみましょう。リスト5はLinuxで広く使われているbashの例です。いずれもCATALINA_HOME/bin/ディレクトリに保存しますが、UNIX版は次のようにして実行可能フラグを与えておきましょう。
また、両者を同じ環境で作ると、UNIX用のスクリプトまで改行コードがCR＋LFになることがあるので注意してください。
|
リスト4 Windows用プロパティ追加スクリプト（setenv.bat）
|
set CATALINA_OPTS=-Duser.webapp.home=c:\myapp
|
|
リスト5 UNIX用プロパティ追加スクリプト（setenv.sh）
|
export CATALINA_OPTS=-Duser.webapp.home=/usr/local/myapp
|
|
リスト6 プロパティを使ったgrantエントリの例
|
grant codeBase "file:///${user.webapp.home}/-"
{
permission java.io.FilePermission
"${user.webapp.home}${/}-", "read,write";
};
|
こうすれば、ポリシーファイルでは${user.webapp.home}とすればアプリケーションディレクトリが参照できます。あまりいい例ではありませんが、このようにしてプロパティを利用します（※6）。
※6 Windows版は、ここでバックスラッシュ表記のパスをURLに記述してしまっています。本来はこうすべきではありません。ここではTomcatにおけるプロパティを用いたポリシーの共通化を説明しています。
最後にいくつか注意点をまとめておきます。
前半に書いたとおり、パーミッション自体を作成してカスタマイズできるアーキテクチャですから、オープンソースやサードパーティなどのライブラリを調子に乗って利用していくと、ある日突然見たことも聞いたこともないパーミッションを要求する例外が発生することもあります。
ライブラリを使うこと自体はまったく問題ありませんが、パーミッションによる例外であることを見抜く経験は必要になります。例外のスタックトレースを見て、SecurityManagerの処理中に発生するなど、いくつかの特徴は見慣れておくべきでしょう。
また、分散オブジェクトなどでサービスを提供した場合のポリシーは、サービスのクライアント側がサーバー側へ入り込んで動作するように記述する必要があります。つまり、クライアント側で、サーバー側のリソースにアクセスする権利が付与される必要のあるケースがあります。
＊
以上、駆け足でしたがJava2プラットフォームセキュリティの簡単な利用方法が理解できたでしょうか。
このセキュリティのアーキテクチャは非常に柔軟ですが、現実のところ、セキュリティポリシーを書けばすむということがほとんどだと思います。
関連リンク
 JAVA Developer
定期購読のご案内
バックナンバー販売協力店
|
JAVA Developer 10月号
大特集
再入門 J2SE
特集2 Oracle9i Application Server
［特別企画］
・例外処理のメカニズム
・データベース移行術（２）
「Oracle→DB2編」
・Tomcatで試すJava2セキュリティ
|
| 
