0

Is there some sort of limit to what privileged actions are permitted even for signed applets? Here is the stack trace:

Exception in thread "AWT-EventQueue-2" java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.skype) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkLink(SecurityManager.java:818) at java.lang.Runtime.loadLibrary0(Runtime.java:817) at java.lang.System.loadLibrary(System.java:1045) at com.skype.connector.ConnectorUtils.loadLibrary(ConnectorUtils.java:321) at com.skype.connector.osx.SkypeFramework.init(SkypeFramework.java:44) at com.skype.connector.osx.OSXConnector.initializeImpl(OSXConnector.java:107) at com.skype.connector.Connector.initialize(Connector.java:485) at com.skype.connector.osx.OSXConnector.isRunning(OSXConnector.java:86) at com.skype.Skype.isRunning(Skype.java:172)

Chry Cheng
  • 3,378
  • 5
  • 47
  • 79

2 Answers2

0

Found the problem. The privileged action is in my applet and my applet's jar is signed but the code that's needing the privileges is in another jar that's not signed. Signing that other jar fixed the problem. Another thing is that even when I took the call out of the privileged action wrapper, it still works so long as the jars are signed.

Chry Cheng
  • 3,378
  • 5
  • 47
  • 79
  • Recent versions of the JRE should prevent (that is, raise a dialog box) applets and WebStart applications mixing signed and unsigned code (unless explicitly permitted by the signed jars, and then only through a different class loader). – Tom Hawtin - tackline May 04 '11 at 13:06
-1

Is there some sort of limit to what privileged actions are permitted even for signed applets?

I would expect so, given that a trusted applet (without any JS involved) is unable to call some methods (e.g. System.exit(int)). While a trusted applet or JWS application has a much more permissive security manager, they still have a security manager.

You might try calling System.setSecurityManager(null) before the code gets to that point to test that theory. If it turns out to now work, don't use that as the production code, instead install a custom SecurityManager that allows the current permissions as well as the one of specific interest.

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • 1
    Trusted applets should have all permissions, so `System.exit(int)` should "work". You could have a security manager which always denied without checking anything. However, PlugIn 2 should be robust enough, that if you crash out one Java process, a new one will be started up automatically. / `System.setSecurityManager(null);` will clear the security manager for all code in the current process, no matter what the origin. You probably don't want to do this (let alone have your digital signature on it!). – Tom Hawtin - tackline May 03 '11 at 14:26