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

Andrew Azores aazores at redhat.com
Thu Mar 13 13:49:19 UTC 2014

On 03/13/2014 03:29 AM, Jiri Vanek wrote:
> 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.

This doesn't sound so bad to me. The next time you restart your already 
running applet it will have those permissions anyway, unless you're 
trying to be tricky and set the permissions for the second applet only 
while it runs, and want to leave the long-running one alone. But this 
sounds like the user is just asking for trouble at that point. Besides, 
the JNLPPolicy also does work with applet JAR URLs, so if you really are 
in this situation for some reason, you can use that mechanism to provide 
control over the second shorter lived applet as well. You just can't use 
PolicyEditor to do it.

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

Also forgot to mention here - you need extended security set to Low. 
Forcing Sandbox sets the classloader security to Sandbox, but the applet 
is correctly requesting All-permissions. Any security level above Low 
will create a LaunchException because of this, due to 
checkPermissionsAttribute(). IMO this seems like fairly reasonable 
behaviour, although maybe there could also be a check in 
checkPermissionsAttribute() for this - if classloader's security level 
is Sandbox, it's only fatal if the SecurityDelegate does not say that we 
are running in sandbox on purpose? Need your input since permissions 
attribute is your work. This is only tangentially related though, 
perhaps it deserves its own new discussion thread.


Andrew A

More information about the distro-pkg-dev mailing list