Pavel Tisnovsky wrote:
Anthony Petrov wrote:
Hi Pavel,
On 12/02/2010 03:26 PM, Pavel Tisnovsky wrote:
Could you please explain benefits of a separate .policy file over the
current approach of setting the security manager directly in the test
code?
when the test calls System.setSecurityManager( new SecurityManager()
{...} ) then the new security manager is installed, but this kind of
security manager deny the AWT robot because it is the standard
behaviour
of applets (users usually don't want the applet to control theirs mouse
and keyboard).
By default there's no any security policy present, and as such the
default implementation of the SecurityManager permits everything. We
override the checkTopLevelWindow() specifically to make AWT think
there's no toplevelwindow permission present. However, all the rest of
the permissions (including the AWT robot one) must be granted.
If that is not the case, I believe your testing environment picks up
some customized security policy which disallows everything by default.
Could you verify that please?
Hi Anthony,
It seems that my testing environment (its patched JTreg harness 4.0 from
IcedTea6) uses restricting security manager for test which are started
as applets, but only after I explicitly install the manager in the test
itself.
I tried the following: the test is still started as applet (using html
file containing JTreg tags and options) but I simplified it to just four
lines:
System.out.println(System.getSecurityManager());
System.setSecurityManager(new SecurityManager());
System.out.println(System.getSecurityManager());
System.getSecurityManager().checkPermission(new
AWTPermission("createRobot"));
Here are result, it's copy & paste from .jtr file generated by JTreg
harness with added comments which begins and ends with ***:
----------messages:(3/142)----------
command: applet WindowWithWarningTest.html
reason: User specified action: run applet WindowWithWarningTest.html
elapsed time (seconds): 0.59
----------System.out:(2/40)----------
*** the first line of test: security manager is not installed yet ***
null
*** the third line of test: now the security manager is installed ***
java.lang.securitymana...@77f297e7
*** statement on fourth line throws exception - it's not possible to
create AWT robot after the security manager is installed ***
----------System.err:(8/650)----------
java.security.AccessControlException: access denied
(java.awt.AWTPermission crea at
java.security.AccessControlContext.checkPermission(AccessControlConte
at
java.security.AccessController.checkPermission(AccessController.java:
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at WindowWithWarningTest.start(WindowWithWarningTest.java:98)
at
com.sun.javatest.regtest.AppletWrapper$AppletRunnable.run(AppletWrapp
at java.lang.Thread.run(Thread.java:636)
STATUS:Failed.Applet thread threw exception:
java.security.AccessControlExceptio
result: Failed. Execution failed: Applet thread threw exception:
java.security.A
Looks like this is a problem with your patched IcedTea jtreg harness
rather than with the test itself then.
The same behaviour could be also reported on unpatched JTreg Harness 4.0.
(so it's just another reason to update JTreg harness to 4.1 on IcedTea6 ;)
Yes, I've been happily using jtreg 4.1 since it was released earlier
this year and my published OpenJDK 6 regression test results since them
have used this version of jtreg.
-Joe
