[rfc][icedtea-web] Runtime refresh of JNLPPolicy

Andrew Azores aazores at redhat.com
Wed Mar 12 15:29:07 UTC 2014


This patch adds a method to JNLPRuntime to allow the Policy object to be 
refreshed, and adds logic to the JNLPPolicy class (of which the 
runtime's Policy reference is an instance) to:
1) be able to refresh its permissions from the user's policy file
2) read from the policy file on a per-codebase basis, not only per 
applet JAR location

It also adds logic to JNLPClassLoader.SecurityDelegate to call the new 
JNLPRuntime method when the applet is to be run sandboxed, to ensure 
that this is done with the current policy, not an older cached copy in 
case there have been changes since the JVM was started.

These changes are in support of later patches which will add a way to 
launch PolicyEditor from the fully and partially signed applet warning 
dialogs. Without the ability to refresh, the JVM needs to be restarted 
before those changes can take effect, which is not good for usability 
(users have to restart their browser). Without the ability to actually 
check by codebase rather than full JAR url, the user policy files will 
be much more complex than planned, and for users to set custom 
permission levels per-applet will be much more difficult to use.

Manual testing:

(with patch applied)
1) Ensure your policy file is either empty or at least does not contain 
an entry to match the test applet
2) Visit http://caff.de/applettest/Signed.html and run the applet sandboxed
3) Verify that the applet may not print nor save. Close the applet but 
do not exit the browser.
4) Add the following to your policy file:

grant codeBase "http://caff.de/applettest/" {
     permission java.lang.RuntimePermission "queuePrintJob";
     permission java.util.PropertyPermission "*", "read";

5) Without closing your browser, restart the applet (refresh the page, 
or open a new tab and visit again)
6) Verify that the applet may now cause a print dialog to appear, but 
still cannot save files

With patch not applied, granting the applet codebase these permissions 
does not work, so grant the same permissions but to all applets. Check 
that making this change to the policy file without restarting the JVM 
does not actually grant the permissions to the applet, and restarting 
the JVM does grant them.

Automated testing:
Working on it, but not sure if it's actually doable. I need a way to 
keep the JVM running between runs of an applet, which I don't know if we 
can do. Any ideas?


Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: runtime-policy-refresh.patch
Type: text/x-patch
Size: 3214 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140312/a1e42691/runtime-policy-refresh-0001.patch>

More information about the distro-pkg-dev mailing list