7

Java 7（特にアップデート4）では、すべてのユーザーがWebstartアプリでこれを確認し始めたことに気づき始めました。

[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More

ここで、CLASSNAME =アプリ実行中のいくつかのjarからのランダムなポイントでほぼすべてのクラスが発生し、いくつかの動作が中断されます。ユーザーがJava6を使用する場合、問題はありません。ちょうど7（アップデート4）。メインアプリケーションjarとそのライブラリjarの両方のすべてのjarに署名します。つまり、ウェブスタートアプリを起動したユーザーには、黄色や赤ではなく青い盾が表示されます。

ユーザーがJava7にアップグレードする頻度が高くなっているため、これは明らかに問題です。以前のインストール（動作）を使用するか、新しいインストールをインストールすることにより、ユーザーのマシンでJava6を使用するようにアプリを強制しようとしました。リソースの周りにj2seversion= "1.6"タグがありますが、これはそれ自体の問題を引き起こし、おそらくそれ自体のスレッド（自動jreインストール部分）にするのが最善でしょう。

OracleはJava7u4でWebstartのセキュリティを破りましたか？このセキュリティ例外の問題を解決するにはどうすればよいですか？

4

5 に答える 5

6

1.7.07でも同じ問題が発生しました。クラスの読み込み中に、Webstartアプリケーションがランダムに失敗し、同じエラーメッセージが表示されました。このページのオラクルフォーラムで興味深い回避策を見つけました。最後の回答は、問題の回避策（Java 6）について説明しています。jarの署名への参照はソフト参照として保持され、ガベージコレクションされる可能性があり、これによりエラーメッセージが表示されます。これは、いくつかの追加行を使用してJava7に採用できます。

// Java 1.7
callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);
于 2012-11-22T13:41:57.483 に答える
3

jarsignersの元の作者だけがチェックインをハックします。私は、最初にハックを共有した別の開発者からここに指示されました。

これに対する彼の継続的な調査に基づいて、ハックへの呼び出しに以下を追加する必要があります

callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);

callNoArgMethod("getManifest", jar);
makeHardLink("manRef", jar, n);

マニフェストコールは、この投稿の解決策の一部ではありませんでした。それらは、問題を再現するために受け入れテストが作成されたときに見つかりました。

この新しい情報に基づいて、アプローチを変更し、リフレクションを使用してすべての「get」メソッドを呼び出します（getメソッドの呼び出しは、ソフトリファレンスがまだ入力されていない場合は、最初に入力する必要があります）。

次に、CachedJarFileクラスのすべてのソフト参照を反射的に検出し、それらへのハードリンクを作成します。

これにより、CachedJarFileが所定の位置に留まり、ハッキングの基本的な前提が真である限り、内部の名前変更/リファクタリングからソリューションを将来にわたって保証できるはずです。（つまり、softreferencesをhardreferencesにします。

于 2013-02-18T23:48:35.680 に答える
2

このバグが発生している可能性があります。

バグステータスは、7u4で修正が提供されたことを示しています。しかし、それはあなたが言っていることとは相容れません。おそらく「修正」が壊れます...。

それまでの間、「squaat」によるバグに関するコメントには、考えられる回避策が記載されています。たとえば、初期ヒープサイズを増やしたり、プリローダーを使用して一部のJARを強制的に早くロードしたりします。

于 2012-06-05T22:29:27.217 に答える
1

JRE 8アップデート91にアップデートした後も、同じ問題が発生します。以前のリリース1.6、1.7、1.8アップデート77では、アプリケーションは正常に動作します。

Oracleは、JRE 1.6のバグに存在していたバグを再導入しましたか？

私が見つけた唯一の回避策は、Javaコントロールパネルからの混合コード制御を無効にすることです。

それを私が直した。問題は、私のアプリケーションで使用されているライブラリにありました。jarファイルに存在するMANIFEST.MFは次のとおりです。

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Built-By: wolf

Name: common
Specification-Title: swixml
Specification-Vendor: swixml.org
Specification-Version: 1.6
Implementation-Title: org.swixml
Implementation-Vendor: swixml.org
Implementation-Version: 1.6 beta 1 (#151)

「Name」プロパティは、ここに記載されているリソース固有のエントリに使用されますhttp://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

このjarに署名すると、「名前」エントリはリソースとして解釈されますが、署名するリソースはありません。アプリケーションが起動されると、javawsは、MANIFEST.MFで報告されたリソースと、アプリケーションをブロックしているjar内の有効なリソースとの間に不一致を検出します。

于 2016-04-20T15:55:31.507 に答える
0

私はJRE7u5を使用して同じ症状に苦しんでいます。まったく同じアプリケーションWebが、JRE6u33を使用して問題なく起動しました。

私の場合、問題は私の拡張jnlpファイルの1つが原因でした。マスターjnlpファイルはすべての権限のセキュリティを指定しましたが、拡張機能jnlpは特定のセキュリティ要件を宣言していません（空のセキュリティタグのみ）。

これにより、拡張jarがサンドボックスにロードされました。どうやら、Java 7は、すべて署名されていても、セキュリティ要件が異なるjarの混合を受け入れないようです。

この問題は、すべての拡張子jnlpファイルがマスターjnlpファイルと同じセキュリティ要件を指定していることを確認することで修正されました。

于 2012-06-26T05:22:58.870 に答える