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

[Jiri Vanek]

On 03/12/2014 04:29 PM, Andrew Azores wrote:

The idea and code looks ok, but I have an fault in mind:

When some applet is already running - and have some permissions already. You visit new applet, set 
different permissions for it and you reload the permissions, will not the running applet be affected 
by those new too?

When they do not share match in codebases, that probably do not hurt, but if they do?

The possible fix may be permissions per classloader. It would be probably right thing, but it scares me.

> 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,
>