Java Security Privileges Required by Silk Test Classic

Before reviewing your security privileges, make sure that you have configured Silk Test Classic Java support.

Required security privileges

In order to load the Silk Test Classic Java support files, Silk Test Classic must have the appropriate Java security privileges. At a minimum, Silk Test Classic requires the following abilities:
  • Create a new thread.
  • Access members of classes loaded by your application.
  • Create, read from, and write to file on a local drive.
  • Access, connect, listen and send information through sockets.
  • Access AWT event queue.
  • Access system properties.
For standalone applications, the security policy is set in the java.security file which is located in JRE/lib/security. By default this file contains the following line:
Policy.provider = sun.security.provider.PolicyFile
which means that the standard policy file should be used. The standard policy file, java.policy, is located in the same folder, JRE/lib/security. It contains the following code that gives all necessary permission to any file located in lib\ext directory:
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*"{permission java.security.AllPermission;};

Silk Test Classic has the necessary privileges, if the SilkTest_Java3.jar file is in this directory and the JVM runs with the default set of security permissions.

If you have changed the Java security policy

The system administrator can change security policy by starting the JVM with the following option:
java _Djava.security.policy=Myown.policy MyApp
In this case the custom policy file Myown.policy should contain the following lines that grant all permission to classes from the lib\ext directory:
grant codeBase "file:${java.home}/lib/ext/*"{permission java.security.AllPermission;};

The default java.policy may also be changed implicitly, for example, when the application uses an RMI server with the custom RMISecurityManager and the client security policy. In cases like these, the client security policy should grant all required permissions to Silk Test Classic by including the code listed above.

In some cases, setting these permissions may not provide Silk Test Classic with the necessary security privileges. The cause of the problem may be that permissions are frame specific. So if Silk Test Classic runs in the context of frames (thread) in which it does not have the necessary permissions, it may fail. In cases like this in which the client does not trust code running in the context of the AWT event thread, you need to set the parameter ThreadSafe=False in the javaex.ini in the <Silk Test installation>/extend directory. This prevents the Silk Test Classic Java code from running in the context of the AWT event thread, preserving permissions granted to Silk Test Classic, but could make the GUI less responsive.