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

[Jiri Vanek]

On 03/12/2014 04:29 PM, Andrew Azores wrote:
> Hi,
>
> 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?
>
> Thanks,
>
based on IRC discussion - ok to go.


J.