Java 1.5 crypto sur OS X - AccessControlException

Question

J'essaie de faire un projet Google App Engine sur OS X (dernier et plus grand). J'utilise des classes de javax.crypto, et je vois une AccessControlException levée quand j'essaie d'initialiser une instance de la classe Mac. Voici la trace de la pile:

WARNING: Nested in java.lang.ExceptionInInitializerError: 
java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.keychain) 
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) 
    at java.security.AccessController.checkPermission(AccessController.java:427) 
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) 
    at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76) 
    at java.lang.SecurityManager.checkLink(SecurityManager.java:818) 
    at java.lang.Runtime.loadLibrary0(Runtime.java:816) 
    at java.lang.System.loadLibrary(System.java:993) 
    at com.apple.crypto.provider.HmacCore.<clinit>(HmacCore.java:26) 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) 
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) 
    at java.lang.reflect.Constructor.newInstance(Constructor.java:494) 
    at java.lang.Class.newInstance0(Class.java:350) 
    at java.lang.Class.newInstance(Class.java:303) 
    at java.security.Provider$Service.newInstance(Provider.java:1130) 
    at javax.crypto.Mac.a(DashoA12275) 
    at javax.crypto.Mac.init(DashoA12275) 

Toutes les idées sur

1 - ce qui a mal tourné et comment fixer

2 - si ce n'est pas réparable (je sais que Apple n'a pas été le meilleur défenseur de Java au cours des dernières années), quelle est une approche alternative?

Answer 1

a trouvé un workround sur google groups:

« Pour contourner le problème local Mac SDK, vous pouvez passer --jvm_flag = -D - enable_all_permissions = true à votre dev_appserver Cela provoquer l'erreur à. allez-y, mais malheureusement aussi désactiver la plupart des contrôles de sécurité dans votre environnement local. "

Answer 2

J'ai une réponse plus complète, mais sans accès à la source de fournisseur crypto d'Apple, nous ne serons jamais complètement sûr quelles autorisations sont nécessaires sur toutes leurs plates-formes. Voici ce que j'ai pu faire travailler pour le léopard des neiges:

Vous devez accorder tout ce codebase a besoin du Crypto les autorisations suivantes:

grand codeBase « votre/code/base » { java.lang permission .RuntimePermission "loadLibrary.keychain"; permission java.io.FilePermission "/ System/Library/Java/Extensions/-", "read"; permission java.io.FilePermission "/ Bibliothèque/Java/Extensions/-", "read"; permission java.io.FilePermission "/System/Library/Frameworks/JavaVM.framework/-", "read"; };

Il semble qu'il existe une sorte de recherche du fichier libkeychain.jnilib qui visite les deux premiers emplacements avant de le trouver dans le répertoire Frameworks sous OSX 10.6.2 for Java 1.6. Les autres versions de Java et d'autres versions du système d'exploitation peuvent avoir des chemins de recherche supplémentaires ou différents. La seule façon de le résoudre pour chaque plate-forme est d'essayer, voir l'exception d'autorisation de sécurité, accorder une autorisation de fichier. Amusement. Un avertissement important, si vous essayez de charger la bibliothèque de chiffrement dans un chargeur de classe qui ne fait pas partie de cette base de code, essayez de le charger dans un autre chargeur de classe qui fait partie de la base de code. déjà chargé dans une autre exception "classloader".