Thoughts on adding getElementClass() method to StackTraceElement?
Alan Bateman
Alan.Bateman at oracle.com
Sun Jun 16 16:42:36 UTC 2013
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.
More information about the core-libs-dev
mailing list