On 16/06/2013 15:29, Nick Williams wrote:
On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
:
SecurityManager.getClassContext() is not available to unpriviliged callers, so
I don't think this a valid argument.
Can you define what "is not available to unprivileged callers" means a little
better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just
fine. I took a look at the Java code, and it's native, so there's no check there. (You
can't instantiate a SecurityManager unless there's not currently a SecurityManager
installed _OR_ the installed SecurityManager allows the creation (installation privilege
isn't checked) of another SecurityManager. Is that what you're talking about?) I took a
look at the native code, and I don't see anything there that would represent a privilege
check that I recognized, but if I understood what you meant a little better I might see
where I'm wrong.
The main thing is that the hack to extend SecurityManager (so that you
can call the protected getClassContext method) is unlikely to work when
there is security manager set. I can't tell what environments you have
tested with but usually it means setting up the security policy so that
the code base of your library is granted the permission. Even then you
might still have an issue because there will likely be frames associated
with other untrusted code on the stack. Maybe your code attempts to
create the security manager does do with so privileges enabled, therwise
everything that could potentially call you would also needed to be
granted this permission.
-Alan.
