[RFC] PR568: LWJGL Applets fail to work with IcedTea Plugin

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2011-03-23 11:35]:
> On 10/13/2010 11:32 AM, Omair Majid wrote:
> >Hi,
> >
> >The attached patch attempts to fix PR568.
> >
> >The LWJGL applet downloads a jar to /tmp/ and then calls
> >getPermissions() using that jar as the CodeSource. Currently, since
> >there is no SecurityDesc for this new location, an exception is thrown.
> >A comment from the source code of LWJGL is:
> >// getPermissions from original classloader is important as it checks //
> >for signed jars and shows any security dialogs needed
> >The attached patch modifies JNLPClassLoader.getPermissions() to treat
> >the new jar the same way it would be treated if it was loaded by
> >initializeResources(). Currently, it checks that the jar is on the local
> >machine and the plugin is being used.
> >
> >The check for a local jar means that any jar on the local machine can
> >now be accessed by an applet (can untrusted applets do this? - they do
> >not have any file permissions). Even though a security dialog will tell
> >the user if the jar is unsigned (or any of the cases that can happen in
> >initializeResources), I am not sure if this is the best solution.
> >
> >I would also like to extend this to all JNLPs in general, but two things
> >are keeping me
> >1. I have not seen any JNLP applications using this.
> >2. I cant see a way to figure out what SecurityDesc should be used
> >(since there is no JNLP file to describe the security permissions that
> >should be granted).
> >
> >Any thoughts or comments?
> >
> 
> Anyone? My personal opinion is to hold off on this for now and add
> it after a new security system is in place.
> 

Agreed. We have made changes that will conflict with this patch set.
Given that this isn't an issue that will be encountered by a majority, I
too vote for post security re-design.

Cheers,
Deepak

> Thanks,
> Omair