views:

227

answers:

1

I'd like to specify certain applets to run with java.security.AllPermission on my computer (for debugging and security testing). However, I don't want to enable all applets that I run to have this permission. So, editing my user Java policy file (which I have ensured is the correct policy file through testing), I try to put this value:

grant codeBase "http://host_where_applet_lives/-" {
 permission java.security.AllPermission;
};

This value fails when the applet tries to do something powerful (create a new Thread, in my case). However, when I put the following value:

grant {
 permission java.security.AllPermission;
};

The applet is able to perform the powerful operation. The only difference is the lack of a codeBase attribute.

An answer to a similar question asked here [1] seemed to suggest (but never show or prove) that AccessController.doPrivileged() calls may be required. To me, this sounds wrong as I don't need that call when I grant the permissions to all applets (the second example I showed). Even if this is a solution, littering the applets I run with AccessController.doPrivileged() calls is not easy or necessarily possible. To top it off, my tests show that this just doesn't work anyway. But I'm happy to hear more ideas around it.

[1] http://stackoverflow.com/questions/1751412/cant-get-allpermission-configured-for-intranet-applet-can-anyone-help

A: 

The answer to the similar question you referenced suggests that calling Java applet code from JavaScript may lead to a SecurityException because the AccessController will do a stack inspection and fail because of the untrusted JavaScript. I tried out the code and sure enough, Firefox won't run the applet called by JavaScript without a doPrivileged() call but Safari will (at least on Mac OSX).

If you are calling your applet from JavaScript, you could try using the Applet.paint() method instead to automatically invoke your applet. Or, you could use the doPrivileged() method to short-circuit the stack inspection, and give yourself whatever privilege you need. Of course, then any untrusted code would be able to call into your privileged code.

alsmola
Unfortunately the applet in question isn't being invoked through JavaScript/LiveConnect, etc., so those items shouldn't be found on the stack. Btw, hai!
nahsra
If the Applet isn't being invoked via JavaScript, you should be able to grant it AllPerrmissions by its URL in the policy file. I've verified it works in Firefox and Safari on Mac OSX. Maybe it's your browser that's misbehaving?And, what's up :)
alsmola
That's the point of the question - that specifying it's URL doesn't work. Maybe that ancient Mac JDK has something to do with it. =P I'm running 1.6.0u16 and I've tested across IE/Firefox/Chrome.
nahsra
Which JVM are you using on the Mac OSX? Sun/IBM/Open/Apple/etc?
nahsra