- PR -

自作SecurityManagerについて

«前のページへ 1|2
投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-06-26 14:58
アプリケーション内のjarファイルのライフサイクルはどうなっているのでしょうか。

ホットデプロイということなので、WebappClassLoaderを親クラスローダとして持つ、
独自のクラスローダを作成して管理しているように思いますが・・・

クラスローダをキーとし、セキュリティマネージャを値とする、WeakHashMapを作成して、
サーブレットフィルタで設定してあげるのが現実的っぽい感じがするのですが。
づか
会議室デビュー日: 2007/06/26
投稿数: 15
お住まい・勤務地: Tokyo, Japan
投稿日時: 2007-06-26 17:02
はじめまして、かつのりさん。
そして、こんにちはみなさん。

実は、Alinous-Coreはすべて、同一コンテキスト内で処理しています。

web.xmlの中では

<servlet-mapping>
<servlet-name>Alinous_Servlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

と言う風にして、中の処理は、全部一つのサーブレットで振り分けるような仕組みになっています。

protected void service(HttpServletRequest httpRequest, HttpServletResponse httpResponce)
throws ServletException, IOException
{
String contextPath = httpRequest.getContextPath();
String webPath = httpRequest.getRequestURI();

if(webPath != null && !webPath.endsWith(".debug")){
AlinousDebug.debugOut("RequestURI : " +webPath);
}


AccessExecutionUnit accessUnit = this.alinousCore.createAccessExecutionUnit(id);
// debug start
debugThreadInit();

IDesign design = null;
String moduleName = null;
PostContext context = new PostContext(this.alinousCore, accessUnit);
try {
webPath = webPath.substring(contextPath.length()+1, webPath.length()-1);
String osPath = AlinousUtils.getOSPath(webPath);
moduleName = AlinousUtils.getModuleName(osPath);

context.setRequestPath(moduleName);
this.alinousCore.registerAlinousObject(moduleName);
（以下略）

みたいな感じで、どこのフォルダのどのファイルを取ってくるとか、その辺は、Alinous-Coreの中心部であるAlinous-Coreが全部仕切っていて、ほとんどJ2EEとかServletとかを無視しまくった実装になっています。

コンテキストでわけるのは、単一コンテキストでなので無理そうです。なので、今は、サーバー側でデバッグ用に何本スレッドが走っていて、どのスレッドがどの変数スタックや変数領域を使っているか監視する仕組みをもじったような仕組みを考えています。

ThreadIdが

Thread th = Thread.currentThread();
Long thId = new Long(th.getId());

という形で取れるので、

Map<Long, MySecurityContextBean> securityInfo

※MySecurityContextBeanは、リクエストのPATHとバーチャルホストのホスト名をもたせる

みたいな変数を用意して、これに自作SecurityManagerがアクセスして判断するような仕組みを自分でつくるしかないような気がしてきました。
要は、コンテキストを無視した実装にしたから、コンテキストを使ったセキュリティー設定とかが出来ないと言うことなのかもしれません。

づか
会議室デビュー日: 2007/06/26
投稿数: 15
お住まい・勤務地: Tokyo, Japan
投稿日時: 2007-06-26 23:26
自己レスですみません。

今日で、java.lang.SecurityManagerについて調べてみたのですが、当初、危惧していたよりもうまくいきそうです。結局、SecurityManagerを拡張したクラスを作るのですが、オーバーライドするメソッドは

public void checkWrite(String file)
public void checkRead(String file)

の２つで良いことが分かりました。

他にも沢山、SecurityManagerクラスは、メソッドを持っていて、ソースを読んでいて「ああ、どうしよう」とおもったのですが、良く見てみると、ソケットの接続とかマルチキャストとか、GUIのウィンドウのどのスレッドがどのウィンドウハンドラにアクセスできるとかいろいろと機能が多岐に渡っていて、本当にオーバーライドしなくてはいけないものは少ないということが分かってきました。

あとは、他の人が作ったJarのライブラリを読まないようにするのは、ALINOUS_HOMEのLIBフォルダからクラスを読み込むクラスローダーを自作しているので、そのスレッドのリクエストアドレスとホストから、自分はクラスをロードすべきかどうかという処理は、セキュリティーマネージャーではなく、自分で作ったクラスローダー上で実行すべきだと分かってきました。


SecurityManagerクラスっていうのは、簡単に言ってしまえば、Javaの標準ライブラリの中のセキュリティーチェックを入れるべきポイントでチェックを入れられるようにするためのフックの仕組みなんですね。今まで、SecurityManagerに関してはまったく知らなかったのですが、今日でその辺の意味がやっとわかりました。

質問に答えてくださった皆様、ありがとうございました。



_________________
Alinous-Core SQL-HTML Language commiter
Tomohiro Iizuka
http://jp.alinous.org
https://sourceforge.jp/projects/alinous-core/
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）