Signed applet running a PrivilegedAction still fails with an AccessControlException

Question

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)

Answer 1

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.

Answer 2

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.