Where is the default Java policy file that applies to unsigned applets?

Question

When I run an unsigned Java applet in a web browser, it is allowed to do some things and not others. There has got to be a file somewhere that defines this. I think it will probably look something like the list here [ http://www.coderanch.com/t/460650/Websphere/java-security-AccessControlException-Access-denied ] and contain entries like the following:

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"; 

Here is a list of more entries that it might possibly contain: http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html

Here is an informal attempt at listing the restrictions (made by multiple users through trial-and-error, it seems): Restrictions on what an unsigned Java applet can do?

This page [ http://docs.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html ] seems to imply that the only two files that are relevant are ${java.home}\\lib\\security\\java.policy and ${user.home}\\.java.policy . I have a default installation, where I don't have the latter file, and only the former. That file contains only

permission java.lang.RuntimePermission "stopThread";

as well as various PropertyPermission s such as

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

This is how I know that there has got to be an additional default policy file for unsigned applets: I made an applet which starts a new thread, and with the default java.policy file above, it fails with the following error: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") , indicating that nothing has granted it the "modifyThreadGroup" permission. However, when I run it in a browser, it creates the thread successfully.

So the question is: when I run an applet in a browser, where is the policy file which contains this permission "modifyThreadGroup" ? I've searched for it in the JRE directory, but there doesn't seem to be one. Maybe it's not done through a file. Then what grants the applet the "modifyThreadGroup" permission (and others)?

EDIT

Here is the stack trace for the exception that I see:

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)

Answer 1

Specifically for modifyThreadGroup :

• the API docs for Thread constructor point to the Thread(ThreadGroup,Runnable,String) constructor
• the Thread(ThreadGroup,Runnable,String) constructor refers to ThreadGroup.checkAccess on the specified ThreadGroup
• ThreadGroup.checkAccess is documented to call SecurityManager.checkAccess(ThreadGroup)
• SecurityManager.checkAccess(ThreadGroup) API docs says for the implementation within that class:

If the thread group argument is not the system thread group, this method just returns silently.

(It then suggests kind of breaking LSP:

Applications that want a stricter policy should override this method.

)

Extra permissions are added through ordinary Java code. This is kind of necessary if you think about the Same Origin Policy.