适用于未签名小程序的默认Java策略文件在哪里？

当我在web浏览器中运行一个未签名的Java小程序时，它可以执行某些操作，而不能执行其他操作。 一定有一个文件在某个地方定义了这个。我认为它可能看起来像这里的列表[]，并且包含如下条目：

permission java.lang.RuntimePermission "getClassLoader"; 
permission java.lang.RuntimePermission "setFactory"; 
permission java.lang.RuntimePermission "accessClassInPackage.sun.misc"; 
permission java.lang.RuntimePermission "accessClassInPackage.sun.beans.infos"; 
permission java.lang.RuntimePermission "accessDeclaredMembers"; 
permission java.net.SocketPermission "*", "accept, resolve, connect"; 
permission java.util.PropertyPermission "*", "read, write"; 
permission java.security.SecurityPermission "printIdentity"; 
permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; 
permission java.lang.RuntimePermission "modifyThread"; 
permission java.lang.RuntimePermission "modifyThreadGroup"; 
permission java.security.SecurityPermission "getProperty.ssl.SocketFactory.provider"; 

permission java.lang.RuntimePermission "createClassLoader"; 
permission java.lang.RuntimePermission "getProtectionDomain"; 

以下是可能包含的更多条目的列表：

下面是列出限制的非正式尝试（似乎是由多个用户通过反复试验得出的）：

此页面[]似乎暗示只有两个相关文件是

${java.home}\lib\security\java.policy

和

${user.home}\.java.policy

。我有一个默认安装，没有后一个文件，只有前一个。该文件仅包含

permission java.lang.RuntimePermission "stopThread";

以及各种

PropertyPermission

s，如

permission java.util.PropertyPermission "java.version", "read";

这就是为什么我知道对于未签名的小程序必须有一个额外的默认策略文件：我制作了一个小程序，它启动一个新线程，使用上面的默认

java.policy

文件，它会失败，并出现以下错误：

java.security.AccessControlException:access denied（“java.lang.RuntimePermission”“modifyThreadGroup”）

，表示未向其授予

“modifyThreadGroup”

权限。但是，当我在浏览器中运行它时，它成功地创建了线程

所以问题是：当我在浏览器中运行小程序时，包含此权限的策略文件在哪里？我在JRE目录中搜索过它，但似乎没有。也许这不是通过文件完成的。那么是什么授予小程序

“modifyThreadGroup”

权限（以及其他权限）

编辑

下面是我看到的异常的堆栈跟踪：

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
    at java.security.AccessController.checkPermission(AccessController.java:555)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at sun.applet.AppletSecurity.checkAccess(AppletSecurity.java:252)
    at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:315)
    at java.lang.Thread.init(Thread.java:376)
    at java.lang.Thread.<init>(Thread.java:446)
    at LITSApplet.init(LITSApplet.java:30)
    at sun.applet.AppletPanel.run(AppletPanel.java:434)
    at java.lang.Thread.run(Thread.java:722)

java.security.AccessControlException:拒绝访问（“java.lang.RuntimePermission”“modifyThreadGroup”）
位于java.security.AccessControlContext.checkPermission（AccessControlContext.java:366）
在java.security.AccessController.checkPermission（AccessController.java:555）
位于java.lang.SecurityManager.checkPermission（SecurityManager.java:549）
位于sun.applet.AppletSecurity.checkAccess（AppletSecurity.java:252）
位于java.lang.ThreadGroup.checkAccess（ThreadGroup.java:315）
位于java.lang.Thread.init（Thread.java:376）
位于java.lang.Thread.（Thread.java:446）
在LITSApplet.init（LITSApplet.java:30）
运行（AppletPanel.java:434）
运行（Thread.java:722）

专门针对

modifyThreadGroup

：

• Thread

  构造函数的API文档指向

  线程（ThreadGroup，Runnable，String）

  构造函数

• 线程（ThreadGroup，Runnable，String）

  构造函数引用

  ThreadGroup。在指定的
  ThreadGroup上选中access

• ThreadGroup.checkAccess

  被记录为调用

  SecurityManager.checkAccess（ThreadGroup）

• SecurityManager.checkAccess（ThreadGroup）

  API文档说明了该类中的实现：

如果threadgroup参数不是系统线程组，则 方法只是静默返回

（然后，它提出了破坏LSP的类型：

需要更严格策略的应用程序应覆盖此方法

)

额外的权限是通过普通Java代码添加的。如果您考虑同源策略，这是必要的。

这（更严格的策略）似乎是AppletViewer中正在发生的事情。我已经在问题的编辑中添加了堆栈跟踪。实际情况是，

sun.applet.AppletSecurity扩展了sun.awt.AWTSecurityManager

，虽然传递给它的

checkAccess（…）

的线程组不是系统线程（即具有非空父线程），但它仍然调用

checkPermission（“modifyThreadGroup”）

，任何地方都没有这样的许可。我的结论是AppletViewer并不是一个很好的仿真器，它无法从浏览器环境中获得权限。