[rfc][icedtea-web] set location for jnlpHreffed jnlp file correctly (rh1072013)

Jiri Vanek jvanek at redhat.com
Mon Mar 10 15:44:37 UTC 2014

On 03/10/2014 04:08 PM, Omair Majid wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2014-03-10 10:16]:
>> On 03/08/2014 04:58 AM, Andrew Azores wrote:
>>> No, I don't think there's any way to make applets able to call
>>> System.exit() with the custom policies. Not with the way
>>> JNLPSecurityManager is currently written. I can't think of a valid
>>> reason an applet would need to be able to kill the JVM though... so I
>>> don't think it's worth modifying the security manager to allow this.
>> Well. I was thinking moreover if it is usable as workaround before
>> upstream removes the call.
>> But this lead me to idea - why is system.exit not checked against
>> policies as all other stuff?  But I can probably answer - because
>> there is no such policy?
> The exit permission is not granted by default to applets. This is
> because all applets that are running in the browser share a single JVM.
> If one applet calls System.exit(), all applets will die. This is
> something we do not want, so we don't grant that permission.
> For javaws, the security manager handles this permission like any other,
> allowing sufficiently privileged applications to override it.

Yes, I know this. I was thinking if user can allow i as workaround via custom permissions for special cases (like this one). But

 > http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html
 > There is a permission that's meant for this (exitVM), but it's supposedly automatically granted, which implies any thread can exit the VM if it wants to. This would explain why JNLPSecurityManager doesn't rely on this permission to determine whether applets/applications are allowed to exit.

, apparently it is not possible, because default permission is "allowed".


More information about the distro-pkg-dev mailing list