Tut AccessController.doPrivileged geben, die JavaScript-threads, die Berechtigungen für das signierte Applet?
Ich freue mich auf ein signiertes Applet, das stark den Aufruf aus JavaScript. Natürlich, die threads, stammen von JavaScript sind stärker Sandbox als jeder thread gestartet, direkt aus Java. Zum Beispiel, wenn ein JavaScript-thread-Aufrufe in das Applet und meldet etwas, das bewirkt, dass die log-Datei zu Rollen, wird eine Sicherheitsausnahme ausgelöst. Ein thread gestartet, der direkt in das Applet nicht die Erfahrung diese Sicherheit Ausnahme. Hier die Lösung mit log4j ist die Verwendung der asynchronen appender.
Aber mit anderen Sicherheits-Ausnahmen (zum Beispiel die Nutzung von Apache Axis in der signierten Applet aber in einem JavaScript-thread) gibt es keinen offensichtlichen Weg, um einige asynchrone thread. Sagen wir, ich habe den folgenden code, wenn der Aufruf von einem Java-thread funktionieren wird, und wenn der Aufruf über JavaScript Fehler mit einer SecurityException:
public void someMethodCalledFromJavaScript() {
//Stuff that would throw a SecurityException
}
Ich sehe drei folgenden Optionen, Sie können aber nicht alle gültig sein. Für die Zwecke dieser Diskussion, ignorieren, ob oder nicht die Ausführung synchron oder asynchron, wie das ist, einfach verwaltet werden. Ich bin eine schwierige Zeit das Verständnis der details der security-Modell. Hier sind meine drei mögliche Entscheidungen:
-
Einen neuen Thread starten (wird dieses sogar arbeiten?):
public void someMethodCalledFromJavaScript() { new Thread(new Runnable() { public void run() { //Stuff that would throw a SecurityException } }).start(); }
-
Haben das Applet einen thread bereit zu gehen, zu allen Zeiten, ausgelöst über die JavaScript-Ursprungs-thread (stark vereinfachte code hier):
private volatile boolean doit = false; //This code is running in a Thread, started @ Applet init time public void alwaysWaiting() { while (true) { if (doit) { doit = false; //Stuff that would throw a SecurityException } } } public void someMethodCalledFromJavaScript() { doit = true; }
-
Verwenden AccessController.doPrivileged:
public void someMethodCalledFromJavaScript() { AccessController.doPrivileged(new PrivilegedAction() { public Object run() { //Stuff that would throw a SecurityException return null; } }); }
Nach dem, was ich gelesen AccessController.doPrivileged
führen Sie mit dem Schnittpunkt der aktuellen Sicherheits-privs und die privs der security domain des Codes, den Sie hier aufrufen. Das ergibt keinen Sinn für mich, als wenn Sie mit der Kreuzung eine low und eine high-security Domäne, müssen Sie nur die low-security-domain. Also, klar ich bin etwas nicht zu verstehen.
Den spezifischen SecurityException
ich sehe, ist dieses hier:
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
aber natürlich bin ich neugierig auf den Allgemeinen Fall im Kontext der JavaScript-Aufruf in ein signiertes Applet, und wie kann ich ermöglichen, eine JavaScript-Ursprung-thread für die Ausführung mit der priv ist, der das signierte Applet, als wäre es ein thread, der stammt aus dem rein-Applet.
Welche Auswahl oben wird auch funktionieren, und die sind besser als andere und warum.
- Jeder access control check prüft die Schnittmenge aller stack-frames (einschließlich des stack-Rahmens im Vorfeld der Instanziierung des aktuellen Threads, rekursiv). Wenn die privilegierten geprüft wird, ist nicht in jedem einzelnen frame, die Kreuzung, es schlägt fehl. Wenn es eine
doPrivileged
frame, alle frames im Vorfeld, dass der Rahmen ignoriert. So zum Beispiel, wenn SiedoPrivileged
einige unprivilegierte code, der versucht, eine Datei zu öffnen, ist der check fehl. Ebenso, wenn nicht-privilegierten codedoPrivilege
s Vertrauenswürdige code, der eine Datei öffnet, wird die überprüfung nicht erfolgreich ausgeführt werden. - Aber wenn Sie nicht vertrauenswürdigen code aufgerufen vertrauenswürdigen code und die vertrauenswürdigen code wiederum ruft
doPrivilege
um eine Datei zu öffnen, ist der check erfolgreich sein wird. - Warum schreiben Sie denn nicht, dass so eine Antwort?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Nicht funktionieren, wegen der genannten Gründe unten
Funktioniert natürlich, aber das ist schmerzhafter als der Aufruf
doPrivileged
, hat aber den gleichen Effekt semantisch.Ja, das wird funktionieren.
Jeder access control check prüft die Menge der stack-frames auf dem stack des aktuellen Threads (einschließlich des stack-Rahmens im Vorfeld der Instanziierung des aktuellen Threads, rekursiv). Wenn es eine
doPrivileged
Rahmen, Rahmen im Vorfeld, die Rahmen sind nicht im set enthalten (aber die tatsächlichedoPrivileged
Rahmen ist im Lieferumfang enthalten).Wenn die Berechtigung geprüft wird, ist nicht in jedem einzelnen frame in diesem Satz, der check fehlschlägt.
In anderen Worten, die aktuellen Berechtigungen eines thread sind die Schnittmenge der Privilegien in diesem set.
So zum Beispiel, wenn der privilegierte code
doPrivileged
s einige nicht-privilegierten code, der versucht, eine Datei zu öffnen, ist der check fehl. Ebenso, wenn nicht-privilegierten codedoPrivileged
s-privilegierten code, der eine Datei öffnet, wird die überprüfung nicht erfolgreich ausgeführt werden. Aber wenn nicht-privilegierten code ruft privilegierten code und den privilegierten-code wiederum ruftdoPrivileged
um eine Datei zu öffnen, ist der check erfolgreich sein wird.In der Theorie, Sie sollte in der Lage sein, zu erteilen, Ihre Java-Codebasis, die Berechtigungen es braucht (vielleicht Zugriff auf einige isolierte Verzeichnis), und erteilt dann die gleichen Privilegien, um den JavaScript-code, dass er mit diesem privilegierten code, aber ich bezweifle, jeder browser hat solche Eigenschaften. Ich bin überrascht, JavaScript und läuft sogar in einer anderen Sicherheitsdomäne als Java.
Habe ich noch nie getan, JavaScript<->Java-interop, aber es scheint egal, was Sie gehen zu müssen, um die Methoden, die aufgerufen werden, indem Sie JavaScript verwenden
doPrivileged
Blöcke auf Ihren gesamten Körper.EDIT: Als Sami sagte, werden vorsichtig beim aufrufen
doPrivileged
Blöcke innerhalb der privilegierte code (und Lesen Sie seine Antwort).Ich würde gehen mit den doPrivileged. Just bewusst sein, dass jeder, der Zugang hat zu Ihrer applet können es herunterladen und legen Sie es auf Ihrer Website und haben Ihre eigenen bösartigen javascript rufen Sie es in einer Weise, die Sie nicht vorstellen.
Auswirkungen auf die Sicherheit der anderen Lösungen sind ziemlich die gleichen (EDIT: obwohl das erstellen eines neuen Threads funktioniert nicht, wie Longpoke darauf hingewiesen), aber Sie sind komplizierter. Also ich sehe keinen Vorteil mit Ihnen.
Den AccessController.doPrivileged betrachtet den Schutz Domäne nur den unmittelbaren Aufrufer. In Ihrem Beispiel ist die Klasse, wo Ihre Methode someMethodCalledFromJavaScript definiert ist. Wenn diese Vertrauenswürdige Klasse in der jar ist, spielt es keine Rolle, dass die nicht vertrauenswürdigen Javascript-Aufruf.