問題タブ [securitymanager]

Tomcat サーブレットに多数のファイルをダウンロードさせようとしていますが、Apache と Tomcat が同じサーバーで実行されているため、動作しないと思います。Apache を実行していないサーバーでテストしましたが、すべて問題ありません。

new Url( fileUrl ).openStream() を使用しようとしたときに発生する例外は次のとおりです。

Apache を同時に実行しながら、Tomcat 経由で http ダウンロードを実行するにはどうすればよいですか? 私は立ち往生していますか？

編集:
私が何をしても、Tomcatを乗り越えることはできません。03catalina.policy は次のとおりです。

// ========== CATALINA コードの許可 ================================== ====

署名されていないアプレットとして実行される Java ライブラリ コードがいくつかあります。このため、一部の操作 (システム プロパティのチェックなど) を実行できない場合があります。

コードが制限された操作を実行していないこと、またはセキュリティ例外を正しく処理していることを確認できるように、アプレットのようなセキュリティ マネージャーを使用していくつかの単体テストを実行したいと考えています。

これらの単体テストを現実的な Security-Manager 構成で実行する最良の方法は何ですか? ソリューションは、JUnit と統合できるものが望ましいでしょう。

setAccessible() が呼び出されているものの詳細に応じて、Java の SecurityManager が ReflectPermission("suppressAccessChecks") を選択的に付与する方法はありますか? これを行う方法がわかりません。

一部のサンドボックス化されたコードでは、setAccessible() リフレクション API の呼び出しを許可すると非常に便利です (さまざまな動的 JVM 言語の実行など) 。サンドボックス化されたコードで。

これが不可能な場合、ReflectPermission("suppressAccessChecks") を選択的に付与する以外の代替提案はありますか? SecurityManager.checkMemberAccess() が十分に制限されている場合、すべての場合に許可しても安全でしょうか?

F＃で非常に小さな.NETアプリを作成しようとしました。

小さな文字列を別の文字列に変換し、その結果を次のようにコンソールに出力するだけです。

convert.exemyString==>「myConvertedString」のようなものを出力します

dottraceを使用してパフォーマンスを分析しました。

• 私の実際の文字列変換で26％（168ms）（これは問題ないと思います）
• System.Security.SecurityManagerのResolvePolicyで65,80％（425ms）

すべての実行で500ミリ秒を超える実行時間は遅すぎます。これを改善するために何かできることはありますか？

今回は最初の呼び出しだけが必要な場合はOKです。

よろしく、フォーク

JDKよりも多くの機能を備えたJavaSecurityManagerの他の実装（OSSプロジェクトなど）はありますか？

私はのような機能を探しています

• 実行時に構成可能
• security.policy実行時に更新可能なポリシー、ファイル以外のデータソースから読み取る
• スレッド対応、たとえばスレッドごとに異なるポリシー
• 上位レベルのポリシー（例：「ネットワーク機能を無効にするが、JDBCトラフィックは許可する」
• 一般的な事前定義されたポリシー、たとえば「file.encodingまたはなどの通常のシステムプロパティへの読み取りline.separatorアクセスを許可するが、user.homeへの読み取りアクセスは許可しない」
• トレースログの監視と監査。例：「すべてのファイルアクセスをログに記録し、knownhost.example.orgに送信されないすべてのネットワークアクセスをログに記録する」
• 管理者が権限を付与するまで権限を「要求」するジョブをブロックし、スレッド/ジョブを続行させます
• ..。

SecurityManagerアプリケーションサーバー（少なくとも商用サーバー）には、独自の実装または少なくとも独自のポリシー構成があると確信しています。同様の要件を持つ無料のプロジェクトがあるかどうか疑問に思います。

Ubuntu Karmic用にパッケージ化されたTomcat 6.0.24を使用しています。Ubuntu の Tomcat パッケージのデフォルトのセキュリティ ポリシーはかなり厳格ですが、単純に見えます。には/var/lib/tomcat6/conf/policy.d、デフォルト ポリシーを確立するさまざまなファイルがあります。

最初に注目する価値があります：

• ストックTomcatインストールをまったく変更していません-共通のlibディレクトリに新しいjarを入れたり、server.xml変更したりしません.warファイルをwebappsディレクトリに配置することが唯一の展開アクションです。
• 私が展開しているWebアプリケーションは、このデフォルトポリシーの下で何千ものアクセス拒否で失敗します（-Djava.security.debug="access,stack,failure"システムプロパティのおかげでログに報告されます）。
• セキュリティ マネージャーを完全にオフにすると、エラーはまったく発生せず、適切なアプリ機能が得られます

私がやりたいのは、アプリケーション固有のセキュリティ ポリシー ファイルをpolicy.dディレクトリに追加することです。これは推奨される方法のようです。これを追加しましたpolicy.d/100myapp.policy（出発点として-最終的には、付与された権限をアプリが実際に必要とするものだけに戻したいと思います）：

codeBase正しい宣言を見つけようとする際のスラッシングに注意してください。それはおそらく私の根本的な問題だと思います。

とにかく、上記 (実際には最初の 2 つの付与のみが効果があるように見えます)はほとんど機能します。何千ものアクセス拒否がなくなり、1 つだけが残っています。関連するスタック トレース:

拒否をトリガーしている実際のファイルは無関係であると私は確信しています。これは、オプションの構成パラメーターをチェックするプロパティ ファイルです。興味深いのは、次のことです。

1. このコンテキストには存在しません
2. ファイルが存在しないという事実は、単に false を返すのではなく、セキュリティ例外をスローすることになりますjava.io.File.exists()(ただし、これは読み取り許可のセマンティクスの問題だと思います)。

別の回避策 (Tomcat でセキュリティ マネージャーを無効にする以外に) は、ポリシー ファイルに無制限のアクセス許可を追加することです。

これは、セキュリティ マネージャをオフにすることと機能的に同等であると思います。

助成金の宣言が微妙に間違っているに違いないと思いますがcodeBase、現時点ではそれを見ていません。

Jruby スクリプトに Java Security Manager を使用する場合、特定のスクリプトだけに完全な権限を与えることは可能ですか?

ポリシーファイル以外の方法でアクセス許可を付与することはできますか？私が達成したいのは、実行時に変更できる権限ベースのシステムです。

Tomcat で使用する Web アプリケーションを作成しました。スプリング次第です。アクセスしようとすると、次の例外があります。

tomcat のドキュメントを読んだところ、セキュリティを構成する必要があることがわかりました。
「/usr/share/tomcat/conf/catalina.policy」に次の行を追加しました。

しかし、それは役に立ちませんでした。追加するには、次のコマンドを貼り付けて Tomcat をインストールしました。

サーバーを再起動しました。プロジェクトは指定された場所に存在します。

私は何を間違っていますか？

追加のjarをサーバーのlibフォルダーにコピーせずに、サーバー上の変更をできるだけ少なくしたいと思います。

じぶんの

Tomcat バージョン = Apache Tomcat/6.0.20

春のバージョン = 3.0.1.RELEASE

スタック トレースは大きすぎてここに投稿できません。リンクをたどって確認してください。

誰でも私を助けることができますか？追加するには、Apache Geronimo で例外なく実行されます。

デフォルトのセキュリティ マネージャーでは、ExecutorService (この場合はThreadPoolExecutor ) を作成すると、それをシャットダウンできず、shutdown()呼び出すだけですぐに終了しますcheckPermission("modifyThread")。

サンJDK:

$ java -Djava.security.manager 現在のスレッド: Thread[main,5,main] Exception in thread "main" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:323) で java.security.AccessController.checkPermission(AccessController.java:546) で java.lang.SecurityManager.checkPermission(SecurityManager.java:532) で java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor. java:1094) で A.main(A.java:22)

OpenJDK:

$ java -Djava.security.manager 現在のスレッド: Thread[main,5,main] Exception in thread "main" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:342) で java.security.AccessController.checkPermission(AccessController.java:553) で java.lang.SecurityManager.checkPermission(SecurityManager.java:549) で java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor. java:711) で java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1351) で A.main(A.java:22) で

どうして？？？？？？？自分だけが制御するスレッド プールを作成してシャットダウンすると、セキュリティにどのような影響がありますか? これは実装のバグですか、それとも何か不足していますか?

ExecutorService.shutdownの仕様を見てみましょう...

以前に送信されたタスクが実行される順序どおりのシャットダウンを開始しますが、新しいタスクは受け入れられません。すでにシャットダウンされている場合、呼び出しによる追加の効果はありません。

例外: SecurityException - セキュリティ マネージャが存在し、この ExecutorService をシャットダウンすると、RuntimePermission("modifyThread") を保持していないか、セキュリティ マネージャの checkAccess メソッドがアクセスを拒否するために、呼び出し元が変更を許可されていないスレッドを操作する可能性がある場合。

これは... とてつもなく曖昧です。この仕様では、ExecutorService のライフサイクル中に作成される「システム スレッド」については何も述べていません。さらに、独自のスレッドを提供できるため、その際に「システム スレッド」が関与してはならないことが証明されています。(上記のサンプルソースで行ったように)

Java SE の実装者は、 がshutdownをレイズすることが可能であることを認識したように感じられるSecurityExceptionので、「オーケー、準拠のためにここにランダムなセキュリティ チェックを追加します」というようなものでした...

問題は、OpenJDK ソース (openjdk-6-src-b20-21_jun_2010) を読むと、スレッドを作成する唯一の方法は、提供された ThreadFactory を呼び出すことであることがわかります(これは、テストケースでは決して呼び出されません。作業を作成せず、prestartCoreThreadまたはpreStartAllCoreThreadsを呼び出しません)。したがって、セキュリティ チェックは、OpenJDK の ThreadPoolExecutor で明らかな理由もなく行われます (sun-jdk-1.6 で行われますが、ソースはありません)。

checkShutdownAccess何かをする前に呼び出されます...

ご覧のとおり、無条件にセキュリティ マネージャーを呼び出しますcheckPermission(shutdownPerm).... shutdownPerm は次のように定義されています... private static final RuntimePermission shutdownPerm = new RuntimePermission("modifyThread");

...システムスレッドmodifyThreadへのアクセスを意味するため、私が知る限り、これはまったく意味がありません。また、ここではシステムスレッドが実行されていません。実際、作業や事前開始を送信しなかったため、スレッドはまったくありません、スレッドがあったとしても、.を渡したので、それらは私のスレッドになります。システムスレッドが関与している場合（関与していない場合）、.ThreadFactorySecurityException

基本的に、システム スレッドへのアクセスをチェックする行を削除できないのはなぜですか? それを必要とするセキュリティ上の意味はありません。そして、他の誰もこの問題に出くわしたのはどうしてですか??? への呼び出しを変更することでこの問題を「解決」した問題トラッカーの投稿を見たことがありますがshutdownNow、shutdown明らかに修正されませんでした。