I\'m looking at a signed Applet that is heavily called from JavaScript. Obviously, the threads that originate from JavaScript are more heavily sandboxed than any thread started
Wont work because of reasons mentioned below
Will work of course, but that's more painful than calling doPrivileged
, yet has the same effect semantically.
Yes this will work.
Every access control check inspects the set of all stack frames on the stack of the current thread (including the stack frame leading up to the instantiation of the current thread, recursively). If there is a doPrivileged
frame, frames leading up to that frame are not included in the set (but the actual doPrivileged
frame is included).
If the privilege being checked is not in every single frame in that set, the check fails.
In other words, the current privileges of a thread are the intersection of privileges in this set.
So for example if privileged code doPrivileged
s some unprivileged code which tries to open a file, the check will fail. Likewise if unprivileged code doPrivileged
s privileged code that opens a file, the check will fail. But if unprivileged code invokes privileged code and the privileged code in turn calls doPrivileged
to open a file, the check will succeed.
In theory, you should be able to only grant your Java codebase the privileges it needs (perhaps access to some isolated directory), and then grant the same privileges to the JavaScript code that will use this privileged code, but I doubt any browser has such features. I'm surprised JavaScript even runs in another protection domain than Java.
I've never done JavaScript<->Java interop, but it seems no matter what you are going to have to make the methods that are invoked by JavaScript use doPrivileged
blocks on their entire body.
EDIT: As Sami said, be careful when invoking doPrivileged
blocks within the privileged code (and read his answer).